I''m not an expert or anything, but it seems to me that the only aspect of Rails which could use a little more DRY is the views. Also, I recognize that I don''t probably know enough about XSLT to make much of an evaluation of whether or not XSLT is a good fit for Rails, but it seems like an obvious way to reduce the amount of repetitive coding of HTML. I did some Googling and found only a couple mentions of XSLT relative to Rails, but one of the mentions of it did a far better job than I''ve done of detailing why I think XSLT should be supported in Rails. You can find that at: http://one.textdrive.com/pipermail/rails/2005-January/001824.html What are some of the opinions of the Rails community on the idea of XSLT within Rails? Are there any other alternatives that provide an efficient, DRY based alternative to building the content of a page on the backend and then rendering the page client side? The attraction to me of XSLT''s approach is that it saves some bandwidth, seems like a natural fit for Rails and AJAX, can be rendered client side (speeding up rendering, reducing server load, etc), and just all around seems like a good idea. HOWEVER, as admitted above, I don''t know enough about XSLT or Rails (yet) to be able to be a very good judge of the matter. Are there any good techniques for circumventing repetitive HTML coding? ...other than by way of render_partial(s)? I''m much obliged for any and all insights into this matter! Regards, Abe Burnett _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On 27/04/05, Abe Burnett <abe.burnett-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I''m not an expert or anything, but it seems to me that the only aspect > of Rails which could use a little more DRY is the views. Also, I > recognize that I don''t probably know enough about XSLT to make much of > an evaluation of whether or not XSLT is a good fit for Rails, but it > seems like an obvious way to reduce the amount of repetitive coding of > HTML. I did some Googling and found only a couple mentions of XSLT > relative to Rails, but one of the mentions of it did a far better job > than I''ve done of detailing why I think XSLT should be supported in > Rails. You can find that at: > > http://one.textdrive.com/pipermail/rails/2005-January/001824.html > > What are some of the opinions of the Rails community on the idea of XSLT > within Rails? Are there any other alternatives that provide an > efficient, DRY based alternative to building the content of a page on > the backend and then rendering the page client side? The attraction to > me of XSLT''s approach is that it saves some bandwidth, seems like a > natural fit for Rails and AJAX, can be rendered client side (speeding up > rendering, reducing server load, etc), and just all around seems like a > good idea. HOWEVER, as admitted above, I don''t know enough about XSLT or > Rails (yet) to be able to be a very good judge of the matter. > > Are there any good techniques for circumventing repetitive HTML coding? > ...other than by way of render_partial(s)?Layouts? It does matter if you use HTML or XSLT, you''re still going to have to write some sort of markup, just instead of writing HTML you''ll write some XML and XSLT. That''s two steps. I''ve done a website using XML and XSLT before, and it''s not really worth the hastle unless you''re serving content in multiple formats. Don''t forget that not all browsers support XSLT, so you''ll have to render some on the server side. -- Phillip Hutchings http://www.sitharus.com/ sitharus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org / sitharus-QrR4M9swfipWk0Htik3J/w@public.gmane.org
Phillip Hutchings wrote:>On 27/04/05, Abe Burnett <abe.burnett-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > >>I''m not an expert or anything, but it seems to me that the only aspect >>of Rails which could use a little more DRY is the views. Also, I >>recognize that I don''t probably know enough about XSLT to make much of >>an evaluation of whether or not XSLT is a good fit for Rails, but it >>seems like an obvious way to reduce the amount of repetitive coding of >>HTML. I did some Googling and found only a couple mentions of XSLT >>relative to Rails, but one of the mentions of it did a far better job >>than I''ve done of detailing why I think XSLT should be supported in >>Rails. You can find that at: >> >>http://one.textdrive.com/pipermail/rails/2005-January/001824.html >> >>What are some of the opinions of the Rails community on the idea of XSLT >>within Rails? Are there any other alternatives that provide an >>efficient, DRY based alternative to building the content of a page on >>the backend and then rendering the page client side? The attraction to >>me of XSLT''s approach is that it saves some bandwidth, seems like a >>natural fit for Rails and AJAX, can be rendered client side (speeding up >>rendering, reducing server load, etc), and just all around seems like a >>good idea. HOWEVER, as admitted above, I don''t know enough about XSLT or >>Rails (yet) to be able to be a very good judge of the matter. >> >>Are there any good techniques for circumventing repetitive HTML coding? >>...other than by way of render_partial(s)? >> >> > >Layouts? > >It does matter if you use HTML or XSLT, you''re still going to have to >write some sort of markup, just instead of writing HTML you''ll write >some XML and XSLT. That''s two steps. I''ve done a website using XML and >XSLT before, and it''s not really worth the hastle unless you''re >serving content in multiple formats. > >Don''t forget that not all browsers support XSLT, so you''ll have to >render some on the server side. > > >Mmmm, good point. Thanks for the sage input Phillip! Any ideas for good client side rendering techniques that you''re aware of? _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
> Mmmm, good point. Thanks for the sage input Phillip! > > Any ideas for good client side rendering techniques that you''re aware of?IE has XML ActiveX classes, though if ActiveX is turned off then it won''t work. I believe Mozilla has XSLT classes now, but I''m not sure how they work. Safari 2 might if you''re lucky. The current school of thought is to leave the rendering on the server, or use browser detection to see if it can work. Several systems use XML, but only when they''re rendering to multiple formats, say if they provide RTF and PDF versions as well as HTML. -- Phillip Hutchings http://www.sitharus.com/ sitharus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org / sitharus-QrR4M9swfipWk0Htik3J/w@public.gmane.org
I would love to see something similar to the Velocity templating engine for Rails. Right now Rails uses the <%= %> syntax, which is exactly like ASP and PHP code is. THere are plenty of good templating engines out there (tag based, attribute based, etc.) I think Rails needs a good templating engine. Sure, some people will argue that its extra overhead to process the templates. But with caching, it shouldn''t be such a big problem. THere are some pretty nice templating engines on this site, but they are for PHP. Anyone care to create Rails verions of them? http://pear.php.net/packages.php?catpid=10&catname=HTML&pageID=2 On 4/26/05, Phillip Hutchings <sitharus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > Mmmm, good point. Thanks for the sage input Phillip! > > > > Any ideas for good client side rendering techniques that you''re aware > of? > > IE has XML ActiveX classes, though if ActiveX is turned off then it > won''t work. I believe Mozilla has XSLT classes now, but I''m not sure > how they work. Safari 2 might if you''re lucky. > > The current school of thought is to leave the rendering on the server, > or use browser detection to see if it can work. Several systems use > XML, but only when they''re rendering to multiple formats, say if they > provide RTF and PDF versions as well as HTML. > > -- > Phillip Hutchings > http://www.sitharus.com/ > sitharus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org / sitharus-QrR4M9swfipWk0Htik3J/w@public.gmane.org > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- - Ramin http://www.getintothis.com/blog _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Apr 26, 2005, at 6:47 PM, Ramin wrote:> I would love to see something similar to the Velocity templating > engine for Rails. Right now Rails uses the <%= %> syntax, which is > exactly like ASP and PHP code is. THere are plenty of good > templating engines out there (tag based, attribute based, etc.) I > think Rails needs a good templating engine.and what would you gain with doing that? there were already several discussions about that, so i''m not going to go deeply into it. but i don''t really see the point of moving away from erb. why reinvent the wheel? ruby is a great template language.
On 27/04/2005, at 11:47 AM, Ramin wrote:> I would love to see something similar to the Velocity templating > engine for Rails. Right now Rails uses the <%= %> syntax, which is > exactly like ASP and PHP code is. THere are plenty of good templating > engines out there (tag based, attribute based, etc.) I think Rails > needs a good templating engine. > > Sure, some people will argue that its extra overhead to process the > templates. But with caching, it shouldn''t be such a big problem. THere > are some pretty nice templating engines on this site, but they are for > PHP. Anyone care to create Rails verions of them?Its not the processing overhead, its the pointlessness of defining another language just for the front-end. You can use amrita if you like: http://amrita2.rubyforge.org/ - tim lucas
Oh man, I am refraining from getting into a discussion about this.. especially the "pointlessness" part. But I wont get into it. I''m a front-end developer, so the font-end is very important to me, thats all I''m going to say. Thanks for the link to Amrita2, looks very interesting. I will check it out. Ramin On 4/27/05, Tim Lucas <t.lucas-l/qNJNvq70OzaBltdDZI6w@public.gmane.org> wrote:> > On 27/04/2005, at 11:47 AM, Ramin wrote: > > I would love to see something similar to the Velocity templating > > engine for Rails. Right now Rails uses the <%= %> syntax, which is > > exactly like ASP and PHP code is. THere are plenty of good templating > > engines out there (tag based, attribute based, etc.) I think Rails > > needs a good templating engine. > > > > Sure, some people will argue that its extra overhead to process the > > templates. But with caching, it shouldn''t be such a big problem. THere > > are some pretty nice templating engines on this site, but they are for > > PHP. Anyone care to create Rails verions of them? > > Its not the processing overhead, its the pointlessness of defining > another language just for the front-end. > > You can use amrita if you like: > http://amrita2.rubyforge.org/ > > - tim lucas > >-- - Ramin http://www.getintothis.com/blog _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
And for those who are interested in this like I am .. here''s another one I found: http://xtemplate.sourceforge.net/ On 4/27/05, Ramin <i8ramin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Oh man, I am refraining from getting into a discussion about this.. > especially the "pointlessness" part. But I wont get into it. I''m a front-end > developer, so the font-end is very important to me, thats all I''m going to > say. > > Thanks for the link to Amrita2, looks very interesting. I will check it > out. > > Ramin > > On 4/27/05, Tim Lucas <t.lucas-l/qNJNvq70OzaBltdDZI6w@public.gmane.org> wrote: > > > > On 27/04/2005, at 11:47 AM, Ramin wrote: > > > I would love to see something similar to the Velocity templating > > > engine for Rails. Right now Rails uses the <%= %> syntax, which is > > > exactly like ASP and PHP code is. THere are plenty of good templating > > > engines out there (tag based, attribute based, etc.) I think Rails > > > needs a good templating engine. > > > > > > Sure, some people will argue that its extra overhead to process the > > > templates. But with caching, it shouldn''t be such a big problem. THere > > > > > are some pretty nice templating engines on this site, but they are for > > > PHP. Anyone care to create Rails verions of them? > > > > Its not the processing overhead, its the pointlessness of defining > > another language just for the front-end. > > > > You can use amrita if you like: > > http://amrita2.rubyforge.org/ > > > > - tim lucas > > > > > > > -- > - Ramin > http://www.getintothis.com/blog >-- - Ramin http://www.getintothis.com/blog _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Even more! Found a whole list here.. http://www.rubygarden.org/ruby?HtmlTemplates My favorites are the following: - Xtemplate (http://xtemplate.sourceforge.net/index.html) - Amrita2 (http://amrita2.rubyforge.org) - Iowa (http://enigo.com/projects/iowa/index.html) - Kwartz (http://www.kuwata-lab.com/kwartz/index.html) Sorry for reposting this information if it has already been posted before. But i''m sure some of you front-end guys will appreciate these templating engines. And for those who will flame me to eternal hell because "Ruby is already a templating engine", please don''t bother replying to this post. I already know Ruby is "good enough". These are just "different options" to the Ruby syntax and totally up to the developer to use them if he/she likes. Lets just leave it at that. Thank you. On 4/27/05, Ramin <i8ramin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > And for those who are interested in this like I am .. here''s another one I > found: > http://xtemplate.sourceforge.net/ > > On 4/27/05, Ramin <i8ramin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > wrote: > > > > Oh man, I am refraining from getting into a discussion about this.. > > especially the "pointlessness" part. But I wont get into it. I''m a front-end > > developer, so the font-end is very important to me, thats all I''m going to > > say. > > > > Thanks for the link to Amrita2, looks very interesting. I will check it > > out. > > > > Ramin > > > > On 4/27/05, Tim Lucas < t.lucas-l/qNJNvq70OzaBltdDZI6w@public.gmane.org> wrote: > > > > > > On 27/04/2005, at 11:47 AM, Ramin wrote: > > > > I would love to see something similar to the Velocity templating > > > > engine for Rails. Right now Rails uses the <%= %> syntax, which is > > > > exactly like ASP and PHP code is. THere are plenty of good > > > templating > > > > engines out there (tag based, attribute based, etc.) I think Rails > > > > needs a good templating engine. > > > > > > > > Sure, some people will argue that its extra overhead to process the > > > > templates. But with caching, it shouldn''t be such a big problem. > > > THere > > > > are some pretty nice templating engines on this site, but they are > > > for > > > > PHP. Anyone care to create Rails verions of them? > > > > > > Its not the processing overhead, its the pointlessness of defining > > > another language just for the front-end. > > > > > > You can use amrita if you like: > > > http://amrita2.rubyforge.org/ > > > > > > - tim lucas > > > > > > > > > > > > -- > > - Ramin > > http://www.getintothis.com/blog > > > > > > -- > - Ramin > http://www.getintothis.com/blog >-- - Ramin http://www.getintothis.com/blog _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails