Does anybody figure they have the perfect solution for managing stylesheets when using layouts and partials? I''d like a way for each partial to automatically include something in the header section of the layout, when it is used. Right now I just have the layout setup to include 3 stylesheets, one called "default", another called the controller name, and another called the action name, but this of course has limitations. I thought there was something in the works to handle this (having things appear in the header that were called in a template or partial), was that idea scrapped? I imagine it presents a few problems, I mean it''s sortof dirty to automatically include stylesheets based on what the page is composed of, I may need to just switch to a controller-based add_stylesheet macro or something... -Jeff
On Aug 19, 2005, at 3:31 PM, Jeffrey Moss wrote:> Does anybody figure they have the perfect solution for managing > stylesheets when using layouts and partials? > > I''d like a way for each partial to automatically include something > in the header section of the layout, when it is used. Right now I > just have the layout setup to include 3 stylesheets, one called > "default", another called the controller name, and another called > the action name, but this of course has limitations. > > I thought there was something in the works to handle this (having > things appear in the header that were called in a template or > partial), was that idea scrapped? I imagine it presents a few > problems, I mean it''s sortof dirty to automatically include > stylesheets based on what the page is composed of, I may need to > just switch to a controller-based add_stylesheet macro or something... >I''ve done the following in the past. Anytime I have another stylesheet I want used (in a partial, for instance), I just do: <% (@stylesheets ||= []) << "my_stylesheet" %> And then in the master layout: <% stylesheet_link_tag(*@stylesheets) if @stylesheets %> It''s simple, easy to extend, and doesn''t require any special infrastructure. - Jamis
Ah so the partials are rendered first then. That is good to know. -Jeff ----- Original Message ----- From: "Jamis Buck" <jamis-uHoyYlH2B+GakBO8gow8eQ@public.gmane.org> To: <rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org> Sent: Friday, August 19, 2005 3:36 PM Subject: Re: [Rails] Good solution for managing stylesheets> On Aug 19, 2005, at 3:31 PM, Jeffrey Moss wrote: > >> Does anybody figure they have the perfect solution for managing >> stylesheets when using layouts and partials? >> >> I''d like a way for each partial to automatically include something >> in the header section of the layout, when it is used. Right now I >> just have the layout setup to include 3 stylesheets, one called >> "default", another called the controller name, and another called >> the action name, but this of course has limitations. >> >> I thought there was something in the works to handle this (having >> things appear in the header that were called in a template or >> partial), was that idea scrapped? I imagine it presents a few >> problems, I mean it''s sortof dirty to automatically include >> stylesheets based on what the page is composed of, I may need to >> just switch to a controller-based add_stylesheet macro or something... >> > > I''ve done the following in the past. Anytime I have another > stylesheet I want used (in a partial, for instance), I just do: > > <% (@stylesheets ||= []) << "my_stylesheet" %> > > And then in the master layout: > > <% stylesheet_link_tag(*@stylesheets) if @stylesheets %> > > It''s simple, easy to extend, and doesn''t require any special > infrastructure. > > - Jamis > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
On 8/19/05, Jeffrey Moss <jeff-61uStg5MtoFWk0Htik3J/w@public.gmane.org> wrote:> Ah so the partials are rendered first then. That is good to know. > > -JeffThat works for other content as well. I generate breadcrumb links like that, or header text. You can send whole blocks of text like so: <% content_for(''whatever'') do -%> lots and lots of wonderful HTML and stuff <% end -%> The rendered output is available as @content_for_whatever then. -- rick http://techno-weenie.net
On Friday 19 August 2005 23:31, Jeffrey Moss wrote:> Does anybody figure they have the perfect solution for managing > stylesheets when using layouts and partials?In this particular case I''m wondering if the effort is worth it. You may get better results, all in all, if you put everything into one stylesheet. The consolidated stylesheet is probably bigger than any combination of stylesheets you would use on one page otherwise, but it has the advantage that it requires just one server hit. If you''re keeping your stylesheets separate for organizational purposes, have a look at my rake task below. For one resulting stylesheet, I have several ERb templates that are combined. The added benefit is that I can use symbolic constants (well, actually variables) to factor out commonalities, say colors and distances. Michael desc "Update stylesheets" task :update_stylesheets do require ''erb'' FileList[File.join(File.dirname(__FILE__), ''stylesheets/*/'')].each do |stylesheet_dir| name = stylesheet_dir.sub(/\/$/, '''') + ''.css'' puts "Updating #{name}..." src = FileList["#{stylesheet_dir}/*.css"].sort.inject('''') do | result, f| result << File.read(f) end File.open(name, ''w+'') do |out| out.puts ERB.new(src).result.gsub(/^\s+/, '''') end end end -- Michael Schuerig Not only does lightning not strike mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org twice, it usually doesn''t strike once. http://www.schuerig.de/michael/ --Salman Rushdie, Fury
Jamis, Sorry to interject... What does the asterisk (*) in the stylesheet_link_tag method call do? Thanks, Frank On 8/19/05, Jamis Buck <jamis-uHoyYlH2B+GakBO8gow8eQ@public.gmane.org> wrote:> On Aug 19, 2005, at 3:31 PM, Jeffrey Moss wrote: > > > Does anybody figure they have the perfect solution for managing > > stylesheets when using layouts and partials? > > > > I''d like a way for each partial to automatically include something > > in the header section of the layout, when it is used. Right now I > > just have the layout setup to include 3 stylesheets, one called > > "default", another called the controller name, and another called > > the action name, but this of course has limitations. > > > > I thought there was something in the works to handle this (having > > things appear in the header that were called in a template or > > partial), was that idea scrapped? I imagine it presents a few > > problems, I mean it''s sortof dirty to automatically include > > stylesheets based on what the page is composed of, I may need to > > just switch to a controller-based add_stylesheet macro or something... > > > > I''ve done the following in the past. Anytime I have another > stylesheet I want used (in a partial, for instance), I just do: > > <% (@stylesheets ||= []) << "my_stylesheet" %> > > And then in the master layout: > > <% stylesheet_link_tag(*@stylesheets) if @stylesheets %> > > It''s simple, easy to extend, and doesn''t require any special > infrastructure. > > - Jamis > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- - Frank FrankManno.com <a href="http://www.spreadfirefox.com/?q=affiliates&id=2496&t=1">Get Firefox!</a>
> Jamis, > > Sorry to interject... What does the asterisk (*) in the > stylesheet_link_tag method call do?Disclaimer: read the programming ruby book for a better explanation than mine :) You sometimes see methods with parameters like that (such as stylesheet_link_tag). This lets you pass in an unlimited number of params, and the method treats it as one variable. def my_method(*args) my_method(1, 2, 3) Now, let''s say you want to call my_method which takes an *arg. If you do this: @numbers = [1,2,3] my_method(@numbers) It will treat @numbers as the first argument only. So, do this: my_method(*@numbers). -- rick http://techno-weenie.net
> You sometimes see methods with parameters like that (such as > stylesheet_link_tag). This lets you pass in an unlimited number of > params, and the method treats it as one variable.Hey Rick, Thanks for clearing that up... I think I do remember reading that in my Ruby book now that you mentioned it. What would that be called (the use of the asterisk)? I''m not sure what to search the index for. Thanks again! -- - Frank FrankManno.com <a href="http://www.spreadfirefox.com/?q=affiliates&id=2496&t=1">Get Firefox!</a>
> In this particular case I''m wondering if the effort is worth it. You may > get better results, all in all, if you put everything into one > stylesheet. The consolidated stylesheet is probably bigger than any > combination of stylesheets you would use on one page otherwise, but it > has the advantage that it requires just one server hit.I''m with Michael on this one... Except in my case, the use of a single access point for the CSS is much easier to maintain. What I usually do is something like this: Main CSS: @import url("master.css"); @import url("ie_only.css"); The main CSS file takes care of importing the others, which allow me to separate IE-specific styles into their own stylesheet. You could also have a stylesheet for forms, tables, etc. Although these are separate stylesheets, you only need to link to your main CSS file within the Rails code. It''s much easier to maintain this way. Just my $0.02. -- - Frank FrankManno.com <a href="http://www.spreadfirefox.com/?q=affiliates&id=2496&t=1">Get Firefox!</a>
I don''t see how this makes maintenance any easier. You still are maintaining multiple stylesheets, it''s just you don''t include them in the templates you include them in your global stylesheet, which IMO is a bigger pain, and doesn''t afford you as much flexibility. Separating IE specific styles into their own stylesheet still requires that you dynamically output the stylesheet name. I think Michael was just talking about a speedy user experience, where he does have a valid point, and I''ve thought about that before, I just don''t think it makes much difference usually, either way you go has tradeoffs. I''m more concerned with where I''m doing all my editing, so ideally i would just be able to embed the style in the HTML elements and have it all extracted into an optimal set of stylesheets by factoring the commonalities on the individual attribute level. THAT would be cool. HTMLTidy has a feature that''s supposed to do this but last time I tried it, a few months ago, it savaged my pages. -Jeff ----- Original Message ----- From: "Frank Manno" <frankmanno-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> To: <rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org> Sent: Friday, August 19, 2005 5:03 PM Subject: Re: [Rails] Re: Good solution for managing stylesheets> In this particular case I''m wondering if the effort is worth it. You may > get better results, all in all, if you put everything into one > stylesheet. The consolidated stylesheet is probably bigger than any > combination of stylesheets you would use on one page otherwise, but it > has the advantage that it requires just one server hit.I''m with Michael on this one... Except in my case, the use of a single access point for the CSS is much easier to maintain. What I usually do is something like this: Main CSS: @import url("master.css"); @import url("ie_only.css"); The main CSS file takes care of importing the others, which allow me to separate IE-specific styles into their own stylesheet. You could also have a stylesheet for forms, tables, etc. Although these are separate stylesheets, you only need to link to your main CSS file within the Rails code. It''s much easier to maintain this way. Just my $0.02. -- - Frank FrankManno.com <a href="http://www.spreadfirefox.com/?q=affiliates&id=2496&t=1">Get Firefox!</a> _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Frank Manno wrote:>>You sometimes see methods with parameters like that (such as >>stylesheet_link_tag). This lets you pass in an unlimited number of >>params, and the method treats it as one variable. > > > Hey Rick, > > Thanks for clearing that up... I think I do remember reading that in > my Ruby book now that you mentioned it. What would that be called > (the use of the asterisk)? I''m not sure what to search the index for.The index has an entry for "* (array argument)" and an entry for "Variable-length argument list" - both of these refer to information on how to declare methods taking arbitrary numbers of arguments. The other point Rick mentioned - prefixing an actual parameter with * in a method call - is mentioned in "Invoking a Method" (p348 in the second edition). I don''t know what it would be called. regards Justin
On Aug 19, 2005, at 8:34 PM, Justin Forder wrote:> Frank Manno wrote: > >>> You sometimes see methods with parameters like that (such as >>> stylesheet_link_tag). This lets you pass in an unlimited number of >>> params, and the method treats it as one variable. >>> >> Hey Rick, >> Thanks for clearing that up... I think I do remember reading that in >> my Ruby book now that you mentioned it. What would that be called >> (the use of the asterisk)? I''m not sure what to search the index >> for. >> > > The index has an entry for "* (array argument)" and an entry for > "Variable-length argument list" - both of these refer to > information on how to declare methods taking arbitrary numbers of > arguments. The other point Rick mentioned - prefixing an actual > parameter with * in a method call - is mentioned in "Invoking a > Method" (p348 in the second edition). I don''t know what it would be > called. > > regards > > Justin > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >I have always heard this *arg notation as splatting because the * looks like a little splat ;-) -Ezra Zygmuntowicz WebMaster Yakima Herald-Republic Newspaper ezra-gdxLOakOTQ9oetBuM9ipNAC/G2K4zDHf@public.gmane.org 509-577-7732
Sorry Jeffrey. I have to disagree about that being cool. It totally ruins all thoughts about design-elements on the pages actually having a common style. Also it would break the DRY. Since you would repeat writing the style-specs over and over again. Evidently - some of these html tags will get different styles, when you don''t want it. Also the style-names generated will never have a chance of being human readable, at least not even close to what we our selves are able to do. Also - if the generator is to generate your css-classes the result is that you probably will have loads of classes defined. Lots more than you really needed, because it needs to cover your "mistakes" where the html tags were supposed to be the same, but you forgot that one style attribute, leading to an extra class in the stylesheet. Actually - working with other people, the basic style-classes are some of the first ones to be defined. Not the final style, but the style-classes. Then we know that the app will be consistent. Like say we say that all article titles are to have the article_title style-classname. Then we use that. Now we are sure (well - never 100% sure of course, we are only people :), that all article-titles look the same. And we can redesign the look of the pages whenever we like to without having to dig into each html tag in the project. Not to mention the happiness for clients that have the application installed and who also wants to do customizing. They have a clear stylesheet to sit down and edit where one can actually understand what''s what. I have even gotten used to adding comments before the classes in the stylesheets to better explain their effects and purpose. I know that it adds to the initial download, it''s just a sacrifice that I''ve chosen to live with. It''s also a document which is cached so it''s really only the first hit that has extra fingerprint. The customer satisfaction (and also developer ease) is well worth it. Anyways it is still possible to use a rake task or similar to cleanse them before release, but leave a second copy behind for documentation perhaps. Hm... Maybe in a separate file, like mystyles.css and mystyles.css.txt. And have the rake task actually move comments to the txt file and css to the css-file. Just for reference. The latter part was an idea that popped up right now, I might look into that later... I recently spent a lot of hours on a project, moving html style attributes into css, and cleaning up the css and giving the classes meaningful names. The old names were most of them like this: .red_bold_with_border Which are good for reading in the html file how it looks. This works until you decide to change the color-definition within the class to yellow. So what do you do now? Change the name to yellow_bold_with_border? Lessons I had to give on this subject was to think of their html output as objects/blocks, and decide what they where or what they contained, *not how they looked*. They finally got it, and code produced now is much better and the output looks coherent at a lot earlier stage. So, sorry Jeffrey. I really, really cannot follow you on that "cool" thing. Regards, Jeffrey Moss wrote:> I don''t see how this makes maintenance any easier. You still are > maintaining multiple stylesheets, it''s just you don''t include them in > the templates you include them in your global stylesheet, which IMO is a > bigger pain, and doesn''t afford you as much flexibility. Separating IE > specific styles into their own stylesheet still requires that you > dynamically output the stylesheet name. > > I think Michael was just talking about a speedy user experience, where > he does have a valid point, and I''ve thought about that before, I just > don''t think it makes much difference usually, either way you go has > tradeoffs. I''m more concerned with where I''m doing all my editing, so > ideally i would just be able to embed the style in the HTML elements and > have it all extracted into an optimal set of stylesheets by factoring > the commonalities on the individual attribute level. THAT would be cool. > HTMLTidy has a feature that''s supposed to do this but last time I tried > it, a few months ago, it savaged my pages. > > -Jeff
Ronny, You raise good points. I wouldn''t consider myself an expert on the topic of web design, I''m looking at it from a programmers perspective. I''d use programmatic HTML generation to solve the problems you brought up, heh heh. But I''ve got to leave room for a web designer to come in and improve my "starter design" is what I call it. I just want the interface to work, and maybe leave my reputation in good standing by accomodating future modifications. Your stylesheet-first design methodology sounds like it might be the answer to a lot of my problems. Thanks for the reply. -Jeff Ronny Hanssen wrote:>Sorry Jeffrey. > >I have to disagree about that being cool. > >It totally ruins all thoughts about design-elements on the pages >actually having a common style. Also it would break the DRY. Since you >would repeat writing the style-specs over and over again. Evidently - >some of these html tags will get different styles, when you don''t want >it. Also the style-names generated will never have a chance of being >human readable, at least not even close to what we our selves are able >to do. Also - if the generator is to generate your css-classes the >result is that you probably will have loads of classes defined. Lots >more than you really needed, because it needs to cover your "mistakes" >where the html tags were supposed to be the same, but you forgot that >one style attribute, leading to an extra class in the stylesheet. >Actually - working with other people, the basic style-classes are some >of the first ones to be defined. Not the final style, but the >style-classes. Then we know that the app will be consistent. Like say we >say that all article titles are to have the article_title >style-classname. Then we use that. Now we are sure (well - never 100% >sure of course, we are only people :), that all article-titles look the >same. And we can redesign the look of the pages whenever we like to >without having to dig into each html tag in the project. Not to mention >the happiness for clients that have the application installed and who >also wants to do customizing. They have a clear stylesheet to sit down >and edit where one can actually understand what''s what. I have even >gotten used to adding comments before the classes in the stylesheets to >better explain their effects and purpose. I know that it adds to the >initial download, it''s just a sacrifice that I''ve chosen to live with. >It''s also a document which is cached so it''s really only the first hit >that has extra fingerprint. The customer satisfaction (and also >developer ease) is well worth it. Anyways it is still possible to use a >rake task or similar to cleanse them before release, but leave a second >copy behind for documentation perhaps. Hm... Maybe in a separate file, >like mystyles.css and mystyles.css.txt. And have the rake task actually >move comments to the txt file and css to the css-file. Just for >reference. The latter part was an idea that popped up right now, I might >look into that later... > >I recently spent a lot of hours on a project, moving html style >attributes into css, and cleaning up the css and giving the classes >meaningful names. The old names were most of them like this: >.red_bold_with_border > >Which are good for reading in the html file how it looks. This works >until you decide to change the color-definition within the class to >yellow. So what do you do now? Change the name to >yellow_bold_with_border? Lessons I had to give on this subject was to >think of their html output as objects/blocks, and decide what they where >or what they contained, *not how they looked*. They finally got it, and >code produced now is much better and the output looks coherent at a lot >earlier stage. > >So, sorry Jeffrey. I really, really cannot follow you on that "cool" thing. > >Regards, > > >Jeffrey Moss wrote: > > >>I don''t see how this makes maintenance any easier. You still are >>maintaining multiple stylesheets, it''s just you don''t include them in >>the templates you include them in your global stylesheet, which IMO is a >>bigger pain, and doesn''t afford you as much flexibility. Separating IE >>specific styles into their own stylesheet still requires that you >>dynamically output the stylesheet name. >> >>I think Michael was just talking about a speedy user experience, where >>he does have a valid point, and I''ve thought about that before, I just >>don''t think it makes much difference usually, either way you go has >>tradeoffs. I''m more concerned with where I''m doing all my editing, so >>ideally i would just be able to embed the style in the HTML elements and >>have it all extracted into an optimal set of stylesheets by factoring >>the commonalities on the individual attribute level. THAT would be cool. >>HTMLTidy has a feature that''s supposed to do this but last time I tried >>it, a few months ago, it savaged my pages. >> >>-Jeff >> >> >_______________________________________________ >Rails mailing list >Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >http://lists.rubyonrails.org/mailman/listinfo/rails > >
Thanks. I understand :) I think it''s good that you liked the "stylesheet-first" part, because it helps you focus on programming, not on designing. The initial stylesheet may only have empty class declarations, but it is still a good start. I guess a handful of styles can take you far. Regards, Ronny Jeff Moss wrote:> Ronny, > > You raise good points. I wouldn''t consider myself an expert on the topic > of web design, I''m looking at it from a programmers perspective. I''d > use programmatic HTML generation to solve the problems you brought up, > heh heh. > > But I''ve got to leave room for a web designer to come in and improve my > "starter design" is what I call it. I just want the interface to work, > and maybe leave my reputation in good standing by accomodating future > modifications. Your stylesheet-first design methodology sounds like it > might be the answer to a lot of my problems. Thanks for the reply. > > -Jeff > > Ronny Hanssen wrote: > >> Sorry Jeffrey. >> >> I have to disagree about that being cool. >> >> It totally ruins all thoughts about design-elements on the pages >> actually having a common style. Also it would break the DRY. Since you >> would repeat writing the style-specs over and over again. Evidently - >> some of these html tags will get different styles, when you don''t want >> it. Also the style-names generated will never have a chance of being >> human readable, at least not even close to what we our selves are able >> to do. Also - if the generator is to generate your css-classes the >> result is that you probably will have loads of classes defined. Lots >> more than you really needed, because it needs to cover your "mistakes" >> where the html tags were supposed to be the same, but you forgot that >> one style attribute, leading to an extra class in the stylesheet. >> Actually - working with other people, the basic style-classes are some >> of the first ones to be defined. Not the final style, but the >> style-classes. Then we know that the app will be consistent. Like say we >> say that all article titles are to have the article_title >> style-classname. Then we use that. Now we are sure (well - never 100% >> sure of course, we are only people :), that all article-titles look the >> same. And we can redesign the look of the pages whenever we like to >> without having to dig into each html tag in the project. Not to mention >> the happiness for clients that have the application installed and who >> also wants to do customizing. They have a clear stylesheet to sit down >> and edit where one can actually understand what''s what. I have even >> gotten used to adding comments before the classes in the stylesheets to >> better explain their effects and purpose. I know that it adds to the >> initial download, it''s just a sacrifice that I''ve chosen to live with. >> It''s also a document which is cached so it''s really only the first hit >> that has extra fingerprint. The customer satisfaction (and also >> developer ease) is well worth it. Anyways it is still possible to use a >> rake task or similar to cleanse them before release, but leave a second >> copy behind for documentation perhaps. Hm... Maybe in a separate file, >> like mystyles.css and mystyles.css.txt. And have the rake task actually >> move comments to the txt file and css to the css-file. Just for >> reference. The latter part was an idea that popped up right now, I might >> look into that later... >> >> I recently spent a lot of hours on a project, moving html style >> attributes into css, and cleaning up the css and giving the classes >> meaningful names. The old names were most of them like this: >> .red_bold_with_border >> >> Which are good for reading in the html file how it looks. This works >> until you decide to change the color-definition within the class to >> yellow. So what do you do now? Change the name to >> yellow_bold_with_border? Lessons I had to give on this subject was to >> think of their html output as objects/blocks, and decide what they where >> or what they contained, *not how they looked*. They finally got it, and >> code produced now is much better and the output looks coherent at a lot >> earlier stage. >> >> So, sorry Jeffrey. I really, really cannot follow you on that "cool" >> thing. >> >> Regards, >> >> >> Jeffrey Moss wrote: >> >> >>> I don''t see how this makes maintenance any easier. You still are >>> maintaining multiple stylesheets, it''s just you don''t include them in >>> the templates you include them in your global stylesheet, which IMO is a >>> bigger pain, and doesn''t afford you as much flexibility. Separating IE >>> specific styles into their own stylesheet still requires that you >>> dynamically output the stylesheet name. >>> >>> I think Michael was just talking about a speedy user experience, where >>> he does have a valid point, and I''ve thought about that before, I just >>> don''t think it makes much difference usually, either way you go has >>> tradeoffs. I''m more concerned with where I''m doing all my editing, so >>> ideally i would just be able to embed the style in the HTML elements and >>> have it all extracted into an optimal set of stylesheets by factoring >>> the commonalities on the individual attribute level. THAT would be cool. >>> HTMLTidy has a feature that''s supposed to do this but last time I tried >>> it, a few months ago, it savaged my pages. >>> >>> -Jeff >>> >> >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> >> > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-- ------------------------------------------------------------------------ /*Ronny Hanssen*/
> The index has an entry for "* (array argument)" and an entry for > "Variable-length argument list" - both of these refer to information on > how to declare methods taking arbitrary numbers of arguments. The other > point Rick mentioned - prefixing an actual parameter with * in a method > call - is mentioned in "Invoking a Method" (p348 in the second edition). > I don''t know what it would be called.Thanks, Justin! I''ll have a look at it tonight... it''ll be a nice refresher. -- - Frank FrankManno.com <a href="http://www.spreadfirefox.com/?q=affiliates&id=2496&t=1">Get Firefox!</a>