Tobias Haagen Michaelsen
2007-Mar-30 14:03 UTC
SV: [Rails-spinoffs] Re: Problem with mixing Rico\Prototype with Atlas controls
You can group your .js et al. files with your control by editing your project
file by hand and adding a ''DepedentUpon'' child element to the
file entry, like this:
<Content Include="path\to\MyControl.js">
<DependentUpon>MyControl.ascx</DependentUpon>
</Content>
I think you might be able to make some template for doing this automatically
when you add new user controls to the project, but I can not remember how - and
I might be completely wrong :-).
To get back a bit on topic, I think the nicest thing to be said about ASP.NET
controls and their long auto-generated IDs, is that you can write something like
$(''<%= MyControl.ClientID %>'') in your mark-up and have
VS verifying it.
-Tobias
________________________________
Fra: rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
[mailto:rubyonrails-spinoffs@googlegroups.com] På vegne af Ryan Gahl
Sendt: 29. marts 2007 16:27
Til: rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
Emne: [Rails-spinoffs] Re: Problem with mixing Rico\Prototype with Atlas
controls
Actually I don''t use master pages. I use a control (widget) based
approach, where each widget has its own .js file to define client side behavior.
I organize things so that each widget then has its own folder, with the .ascx,
.cs, and .js files all together, so they are all right together in the VWD
solution explorer.
But I do know what you mean, and I''m not aware of any trick to do what
you''re looking for. In a Windows Form or class library I think you can
make related .cs files stack by naming one with a .designer.cs extension (with
the same first part of the name) to trick the solution explorer a bit. One guy
on one my old teams did that, but I always kind thought it was a bit hacky. I
liked the results of course, as it made working with his libraries easier, but
just wished VS made this a little easier. I guess it''s not perfect,
lol.
On 3/28/07, Gareth Evans <agrath-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
Yeah I took one look at Atlas and ran for the hills- now I just use prototype
and scriptaculous.
I do find the asp.net ids on server controls painful though, I sometimes use
server controls to speed development up particularly when I do want to perform
actual postbacks- that is changing though.
I usually only use server controls when I want to access the control from the
code-behind, and not just on postback.
I''m all the way over in Auckland, New Zealand- we made slashdot twice
today (that''s a miracle)! (once for something to do with evolution and
again because russian space junk almost took out a plane inbound :)
I found a neat trick with master pages and page-specific onload functions and
that is to have a dummy onload function in the masterpage that checks to see if
a function, eg: Begin exists and calls it if it does- that way you can code each
onload in its own page .js.... Would be nice if i could get VWD/VS to stack the
.js files under the aspx, like it does with the aspx.[cs|vb]
Gareth
On 3/27/07, Ryan Gahl < ryan.gahl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
<mailto:ryan.gahl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > wrote:
I do ajax with .net, but not using MS''s ajax (the framework formerly
known as Atlas).
I''m out of Appleton, WI (it''s about an hour drive North from
Milwaukee if you care to try to place it geographically).
You?
On 3/25/07, Gareth Evans <agrath-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
I dunno Ryan, I do prototype ajax + .net too :)
I think it''s a good combination.
Others might argue otherwise.
Where are you based out of?
Gareth
On 3/23/07, Ryan Gahl < ryan.gahl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
<mailto:ryan.gahl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > wrote:
I am probably close to being the biggest .NET proponent on this list, and I
wouldn''t touch Atlas with a ten foot pole.
I know that doesn''t help your situation in the short term, but you
could probably do yourself a lot of good by ditching Atlas. If you
don''t ditch Atlas, I would imagine you are going to have to be willing
to ditch any other [serious] client side lib you may think to use later on.
Then again, this is coming from someone who has been rolling his own Ajax
controls for quite some time. Like most MS stuff, I''m sure
Atlas''s draw is because you don''t have to touch the innards of
the Ajax technique (innards is a good word).
On 3/22/07, Christophe Porteneuve <
tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org <mailto:tdd@tddsworld.com>
> wrote:
Hey Lee,
Lee a écrit :
> I am trying to include some atlas controls on the same page that I am
> doing a Rico.Accordion. The problem is that if I do this, then the
> tab control I am using disappears and all of my Rico stuff stops
> working. If I comment out the src in of Rico or Prototype, then atlas
> works. And conversely, if I comment out all atlas controls then all
> of my Rico stuff works. I would appreciate any suggestions that
> anyone may have.
I''m no Atlas expert, but I keep hearing it just breaks every other
script around, for instance by extending Object.prototype, and also
because stuff like atlascompat.js breaks W3C DOM behavior to make it
behave more like MSIE''s when in another browser. I hope
I''m not
spreading FUD here, I''m just repeating things I''ve been
seeing time and
again on this list.
I was under the impression that Atlas had so many issues that most
people went with AjaxPro.Net or some other alternative. But maybe that
was back in .NET 1 time... You might want to do a quick scan on
Atlas-related articles at, say, Ajaxian.com <http://ajaxian.com/>
before committing further to
this specific library. AJAX with .NET does not mandate Atlas...
--
Christophe Porteneuve aka TDD
tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org
Athena Group, Inc.
Inquire: 1-920-955-1457
Blog: http://www.someElement.com <http://www.someelement.com/>
--
Ryan Gahl
Application Development Consultant
Athena Group, Inc.
Inquire: 1-920-955-1457
Blog: http://www.someElement.com <http://www.someelement.com/>
--
Ryan Gahl
Application Development Consultant
Athena Group, Inc.
Inquire: 1-920-955-1457
Blog: http://www.someElement.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
Ryan Gahl
2007-Mar-30 14:13 UTC
Re: SV: [Rails-spinoffs] Re: Problem with mixing Rico\Prototype with Atlas controls
Absolutely. The auto generated IDs are a great thing. Especially if one
takes a widget approach to web development. It allows me to have N instances
of the same widget on screen and never have to worry when one instance tries
to access it''s "someElement" that''s its going to
grab some other element on
the page by the same id.
I''ve abstracted prototype''s $() within my widget classes so
that a widget
can do "this.$(''someElement'')" and it automatically
prepends that instance''s
id prior to calling $(). I never have to deal with the long versions of
ids... it just works.
On 3/30/07, Tobias Haagen Michaelsen
<thm-GhZjJAf4V71knbxzx/v8hQ@public.gmane.org>
wrote:>
> You can group your .js et al. files with your control by editing your
> project file by hand and adding a ''DepedentUpon'' child
element to the file
> entry, like this:
>
>
>
> <Content Include="path\to\MyControl.js">
>
> <DependentUpon>MyControl.ascx</DependentUpon>
>
> </Content>
>
>
>
> I think you might be able to make some template for doing this
> automatically when you add new user controls to the project, but I can not
> remember how and I might be completely wrong J.
>
>
>
> To get back a bit on topic, I think the nicest thing to be said about
> ASP.NET controls and their long auto-generated IDs, is that you can write
> something like $(''<%= MyControl.ClientID %>'') in
your mark-up and have VS
> verifying it.
>
>
>
>
>
> -Tobias
> ------------------------------
>
> *Fra:* rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
[mailto:
> rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org] *På vegne af
*Ryan Gahl
> *Sendt:* 29. marts 2007 16:27
> *Til:* rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
> *Emne:* [Rails-spinoffs] Re: Problem with mixing Rico\Prototype with Atlas
> controls
>
>
>
> Actually I don''t use master pages. I use a control (widget) based
> approach, where each widget has its own .js file to define client side
> behavior. I organize things so that each widget then has its own folder,
> with the .ascx, .cs, and .js files all together, so they are all right
> together in the VWD solution explorer.
>
> But I do know what you mean, and I''m not aware of any trick to do
what
> you''re looking for. In a Windows Form or class library I think you
can make
> related .cs files stack by naming one with a .designer.cs extension (with
> the same first part of the name) to trick the solution explorer a bit. One
> guy on one my old teams did that, but I always kind thought it was a bit
> hacky. I liked the results of course, as it made working with his libraries
> easier, but just wished VS made this a little easier. I guess it''s
not
> perfect, lol.
>
> On 3/28/07, *Gareth Evans*
<agrath-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Yeah I took one look at Atlas and ran for the hills- now I just use
> prototype and scriptaculous.
>
> I do find the asp.net ids on server controls painful though, I sometimes
> use server controls to speed development up particularly when I do want to
> perform actual postbacks- that is changing though.
>
> I usually only use server controls when I want to access the control from
> the code-behind, and not just on postback.
>
>
>
> I''m all the way over in Auckland, New Zealand- we made slashdot
twice
> today (that''s a miracle)! (once for something to do with evolution
and again
> because russian space junk almost took out a plane inbound :)
>
>
>
> I found a neat trick with master pages and page-specific onload functions
> and that is to have a dummy onload function in the masterpage that checks
to
> see if a function, eg: Begin exists and calls it if it does- that way you
> can code each onload in its own page .js.... Would be nice if i could get
> VWD/VS to stack the .js files under the aspx, like it does with the
> aspx.[cs|vb]
>
>
>
> Gareth
>
>
>
> On 3/27/07, *Ryan Gahl* <
ryan.gahl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> I do ajax with .net, but not using MS''s ajax (the framework
formerly
> known as Atlas).
>
> I''m out of Appleton, WI (it''s about an hour drive North
from Milwaukee if
> you care to try to place it geographically).
>
> You?
>
>
>
> On 3/25/07, *Gareth Evans*
<agrath-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> I dunno Ryan, I do prototype ajax + .net too :)
>
> I think it''s a good combination.
>
> Others might argue otherwise.
>
> Where are you based out of?
>
>
>
> Gareth
>
>
>
> On 3/23/07, *Ryan Gahl* <
ryan.gahl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > wrote:
>
> I am probably close to being the biggest .NET proponent on this list, and
> I wouldn''t touch Atlas with a ten foot pole.
>
> I know that doesn''t help your situation in the short term, but you
could
> probably do yourself a lot of good by ditching Atlas. If you don''t
ditch
> Atlas, I would imagine you are going to have to be willing to ditch any
> other [serious] client side lib you may think to use later on.
>
> Then again, this is coming from someone who has been rolling his own Ajax
> controls for quite some time. Like most MS stuff, I''m sure
Atlas''s draw is
> because you don''t have to touch the innards of the Ajax technique
(innards
> is a good word).
>
>
> On 3/22/07, *Christophe Porteneuve* <
tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org > wrote:
>
>
> Hey Lee,
>
> Lee a écrit :
> > I am trying to include some atlas controls on the same page that I am
> > doing a Rico.Accordion. The problem is that if I do this, then the
> > tab control I am using disappears and all of my Rico stuff stops
> > working. If I comment out the src in of Rico or Prototype, then atlas
> > works. And conversely, if I comment out all atlas controls then all
> > of my Rico stuff works. I would appreciate any suggestions that
> > anyone may have.
>
> I''m no Atlas expert, but I keep hearing it just breaks every other
> script around, for instance by extending Object.prototype, and also
> because stuff like atlascompat.js breaks W3C DOM behavior to make it
> behave more like MSIE''s when in another browser. I hope
I''m not
> spreading FUD here, I''m just repeating things I''ve been
seeing time and
> again on this list.
>
> I was under the impression that Atlas had so many issues that most
> people went with AjaxPro.Net or some other alternative. But maybe that
> was back in .NET 1 time... You might want to do a quick scan on
> Atlas-related articles at, say, Ajaxian.com <http://ajaxian.com/>
before
> committing further to
> this specific library. AJAX with .NET does not mandate Atlas...
>
> --
> Christophe Porteneuve aka TDD
> tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org
>
> Athena Group, Inc.
> Inquire: 1-920-955-1457
> Blog: http://www.someElement.com <http://www.someelement.com/>
>
>
>
>
> --
>
> Ryan Gahl
> Application Development Consultant
>
>
> Athena Group, Inc.
> Inquire: 1-920-955-1457
> Blog: http://www.someElement.com <http://www.someelement.com/>
>
>
>
>
> --
> Ryan Gahl
> Application Development Consultant
> Athena Group, Inc.
> Inquire: 1-920-955-1457
> Blog: http://www.someElement.com
>
> >
>
--
Ryan Gahl
Application Development Consultant
Athena Group, Inc.
Inquire: 1-920-955-1457
Blog: http://www.someElement.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---