After a brief look at Zope, I fell in love with ZPT, in fact all my subsequent PHP stuff made use of PHPTal. A TAL implementation for rails would knock people''s socks off! just my 2c dylan
Hi! Dylan schrieb folgendes am 12.02.2005:> After a brief look at Zope, I fell in love with ZPT, in fact all my > subsequent PHP stuff made use of PHPTal. > > A TAL implementation for rails would knock people''s socks off!What would be the benefits? All that is possible with Ruby anyway... and you know that already; bye Wolfgang
On Feb 12, 2005, at 13:27 Uhr, Dylan wrote:> After a brief look at Zope, I fell in love with ZPT, in fact all my > subsequent PHP stuff made use of PHPTal. > > A TAL implementation for rails would knock people''s socks off!i totally agree with wolfgang... why? whats the advantage?
On Sat, 12 Feb 2005 12:27:26 +0000, Dylan <b9704-Ku7NbOBBH+dBDgjK7y7TUQ@public.gmane.org> wrote:> A TAL implementation for rails would knock people''s socks off!I''ve always seen a "tag library" approach as something only really necessary for verbose static languages where the syntax is really verbose and fiddly. I''m not sure why its in Zope, perhaps Python isn''t as easy to use in views as Ruby is. Also interested to know what would be the win over compact/expressive Ruby? Leon
Wolfgang Klinger wrote:> What would be the benefits? All that is possible with Ruby anyway... > and you know that already; >I''m thinking purely from a collaboration point of view. With ZPT, the designer''s template doesn''t get broken, it renders perfectly in dreamweaver and other editors whereas rhtml and php files have all the embedded code which forces them to learn at least a little of the language and it also breaks their design - the wysiwyg view isn''t as good as with ZPT because of the embedded code.
Hi All, This is exactly what I "dislike" in Rails :-) I''ve been using Java w/ Tapestry/Velocity, PHP w/ Smarty and Zope w/ ZPT, that keeps the template "clean". I mean, the designer can open the template in any WYSIWYG HTML editor, change some details and keep the template working :-) . And something like this works, but isn''t so beautiful: <sometag <%= omg.a.tag.inside.a.tag.definition %> /> And yes, I''m a purist =) I''ve thinking on doing something like Smarty/Velocity for Ruby/Rails, but i''m too newbie in Ruby to do this =) -- juca On Sat, 12 Feb 2005 13:50:46 +0000, Dylan <b9704-Ku7NbOBBH+dBDgjK7y7TUQ@public.gmane.org> wrote:> Wolfgang Klinger wrote: > > What would be the benefits? All that is possible with Ruby anyway... > > and you know that already; > > > > I''m thinking purely from a collaboration point of view. With ZPT, the > designer''s template doesn''t get broken, it renders perfectly in > dreamweaver and other editors whereas rhtml and php files have all the > embedded code which forces them to learn at least a little of the > language and it also breaks their design - the wysiwyg view isn''t as > good as with ZPT because of the embedded code. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Juraci Krohling Costa wrote:> This is exactly what I "dislike" in Rails :-) > I''ve been using Java w/ Tapestry/Velocity, PHP w/ Smarty and Zope w/ > ZPT, that keeps the template "clean". I mean, the designer can open > the template in any WYSIWYG HTML editor, change some details and keep > the template working :-) . > And something like this works, but isn''t so beautiful: > <sometag <%= omg.a.tag.inside.a.tag.definition %> />I think ruby has a very elegant syntax so it''s much easier for designers to grasp the little that they need to know to make sense of rhtml but given the choice, I''d prefer using an attribute language.> I''ve thinking on doing something like Smarty/Velocity for Ruby/Rails, > but i''m too newbie in Ruby to do this =)ditto. I''m still learning so i don''t mind churning out my own designs, but for serious projects intended for a future release, I always work with (graphic) designers
>> I''ve thinking on doing something like Smarty/Velocity for Ruby/Rails, >> but i''m too newbie in Ruby to do this =)http://amrita.sourceforge.jp/ that looks promising, but I havn''t looked at integrating with rails yet
> I think ruby has a very elegant syntax so it''s much easier for designers > to grasp the little that they need to know to make sense of rhtml but > given the choice, I''d prefer using an attribute language.Me too. I''m loving the ruby sintax =) But, at least in Brasil, the designers generally don''t know HTML, CSS or JavaScript. They do know Dreamweaver (ugh). They can''t be called WEB designers :-). So, its hard to convince them that they need to learn a little bit of Ruby to change a checkbox to a radio button. -- juca On Sat, 12 Feb 2005 14:53:13 +0000, Dylan <b9704-Ku7NbOBBH+dBDgjK7y7TUQ@public.gmane.org> wrote:> Juraci Krohling Costa wrote: > > This is exactly what I "dislike" in Rails :-) > > I''ve been using Java w/ Tapestry/Velocity, PHP w/ Smarty and Zope w/ > > ZPT, that keeps the template "clean". I mean, the designer can open > > the template in any WYSIWYG HTML editor, change some details and keep > > the template working :-) . > > And something like this works, but isn''t so beautiful: > > <sometag <%= omg.a.tag.inside.a.tag.definition %> /> > > I think ruby has a very elegant syntax so it''s much easier for designers > to grasp the little that they need to know to make sense of rhtml but > given the choice, I''d prefer using an attribute language. > > > I''ve thinking on doing something like Smarty/Velocity for Ruby/Rails, > > but i''m too newbie in Ruby to do this =) > > ditto. I''m still learning so i don''t mind churning out my own designs, > but for serious projects intended for a future release, I always work > with (graphic) designers > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- juraci krohling costa
AWESOME!!! That''s so ... great :-) Cleaner than Velocity/Smarty. *juca trying to integrate amrita to rails* On Sat, 12 Feb 2005 14:55:31 +0000, Dylan <b9704-Ku7NbOBBH+dBDgjK7y7TUQ@public.gmane.org> wrote:> >> I''ve thinking on doing something like Smarty/Velocity for Ruby/Rails, > >> but i''m too newbie in Ruby to do this =) > > http://amrita.sourceforge.jp/ > > that looks promising, but I havn''t looked at integrating with rails yet > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- juraci krohling costa
> I''m thinking purely from a collaboration point of view. With ZPT, the > designer''s template doesn''t get broken, it renders perfectly in > dreamweaver and other editors whereas rhtml and php files have all the > embedded code which forces them to learn at least a little of the > language and it also breaks their design - the wysiwyg view isn''t as > good as with ZPT because of the embedded code.In my humble opinion, this is a process smell. Your designers should be integrated enough into the development of the system to have 1) their own sandbox operating under version control and 2) verify their creation against the live system. Since Rails is an environment that doesn''t require recompilation or other programming steps to see changes, this is very possible. Just let your designers change the code directly, reload the page to see the change, commit when happy. If the probably is with WYSIWYG, I''d argue that you''d perhaps like to train your designers in recent HTML/CSS approaches that leaves the templates brain-dead simple and control most everything from the stylesheet. This approach works incredibly well at 37signals where I''m working with 2-3 designers that each have their own sandbox on the development server to live in. I was initially worried that SVN or even rhtml would be a problem. It was not. They picked it up in no time and we''re much happier for it. I think we as programmers tend to shield designers from more productive environments because we think they can''t handle it. We''re wrong, they can. -- David Heinemeier Hansson, http://www.basecamphq.com/ -- Web-based Project Management http://www.rubyonrails.org/ -- Web-application framework for Ruby http://www.loudthinking.com/ -- Broadcasting Brain
> http://amrita.sourceforge.jp/ > > that looks promising, but I havn''t looked at integrating with rails yetamrita is pretty cool. I''d love to see if it could be integrated with Rails. Been meaning to look at that for months (it was around my second thought after seeing rails), but I''ve never gotten around to it. Silly non-ruby life keeps dominating my time. *sigh* I''ve been an amrita fan for a while. It just feels so clean. All templates can just stay in HTML. To be fair, I''m really new to rails. Never had much time to do any real playing yet (ie I''m new on this list, but I''ll be lurking). Cameron p.s. as an aside, AR is awesome. made a little app of mine a lot more fun to tweak. Thanks DHH!
According to Dylan:> http://amrita.sourceforge.jp/ > > that looks promising, but I havn''t looked at integrating with rails yetI''ve worked with Amrita, that''s a very interesting and clean way of doing templates. In fact, that was one of the first topics I discussed with David on IRC... :-) Now, integrating this into Rails would be interesting as it is a very different way to do templating. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto-0kjVc+YyuDZX+h8frlqCcVAUjnlXr6A1@public.gmane.org Darwin snuadh.freenix.org Kernel Version 7.8.0: Wed Dec 22 14:26:17 PST 2004
Cameron McBride <cameron.mcbride-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:>> http://amrita.sourceforge.jp/ >> >> that looks promising, but I havn''t looked at integrating with rails yet > > amrita is pretty cool. I''d love to see if it could be integrated with > Rails. Been meaning to look at that for months (it was around my > second thought after seeing rails), but I''ve never gotten around to > it. Silly non-ruby life keeps dominating my time. *sigh* > > I''ve been an amrita fan for a while. It just feels so clean. All > templates can just stay in HTML. > To be fair, I''m really new to rails. Never had much time to do any > real playing yet (ie I''m new on this list, but I''ll be lurking). > > Cameron > > p.s. as an aside, AR is awesome. made a little app of mine a lot more > fun to tweak. Thanks DHH!I''ve played with Amrita for some time and I can say that API and the whole approach look very nice. Unfortunately, all these template engines that strive for ''purity'' require additional parsing steps to perform during the rendering process. From my benchmarks I can say that Amrita is too slow comparing to ERB. Replying to others about the purity of template language, I wouldn''t work with ''premodonna'' web designers who cannot understand simple rules of ERB template engine. Web application always is a team effort of many parties: programmers, web designers, DBAs, sys admins, etc. They all have to collaborate in some way. Cheers, Kent
On Feb 12, 2005, at 4:27 AM, Dylan wrote:> After a brief look at Zope, I fell in love with ZPT, in fact all my > subsequent PHP stuff made use of PHPTal. > > A TAL implementation for rails would knock people''s socks off!David has said before that he deliberately did not want to put a template language into rails. After all, eruby is itself a template language of sorts and there is no need to waste time creating and learning a new one. As long as you keep only view-related logic in your rhtml files, they should be very easy for a designer to grok. Carl
Ollivier Robert schrieb:> According to Dylan: > >>http://amrita.sourceforge.jp/ >> >>that looks promising, but I havn''t looked at integrating with rails yet > > > I''ve worked with Amrita, that''s a very interesting and clean way of doing > templates. In fact, that was one of the first topics I discussed with > David on IRC... :-) > > Now, integrating this into Rails would be interesting as it is a very > different way to do templating.Even better than Amrita (cause more lightwight) is what Cerise is doing with templates. http://cerise.rubyforge.org/template.html The author saw that Amrita is in a lot of ways too heavy and simplified it. http://rubyforge.org/cgi-bin/viewcvs.cgi/cerise/template.rb?rev=HEAD&cvsroot=cerise&content-type=text/vnd.viewcvs-markup But I don''t know if it is worth it. I feel comfortable knowing that I have the full power of Ruby under my belt. Just in case. Sascha
I''m new to ruby/rails and this list, so, i guess that this thread was already discussed. But what I really don''t understand is why not to do a template engine (or integrate one). I guess that eruby is a jsp-like (asp-like, php-like) template engine. So, it *should* have the same problems. An example: eruby should be so powerfull that "bad programmers" (evil exists =D) CAN put their business logic inside the template. They shouldn''t, but they can. Another point: the world isn''t perfect. So, designers generally think that they should know only design related technologies: html, css, javascript. Period. I''ll be very (very) happy when the designers that I work learn all the template engines that I use. Smarty, Velocity, ZPT, eRuby, Tapestry, etc... Until that, I must provide them templates that they can edit in their ***** applications :-) But that''s ok. I understand that this feature doesn''t belongs to rails. Again, what I doesn''t understand is why not to do a template engine =) -- juca On Sat, 12 Feb 2005 10:58:42 -0800, Carl Youngblood <carlwork-0CEYHQKyN7s@public.gmane.org> wrote:> On Feb 12, 2005, at 4:27 AM, Dylan wrote: > > > After a brief look at Zope, I fell in love with ZPT, in fact all my > > subsequent PHP stuff made use of PHPTal. > > > > A TAL implementation for rails would knock people''s socks off! > > David has said before that he deliberately did not want to put a > template language into rails. After all, eruby is itself a template > language of sorts and there is no need to waste time creating and > learning a new one. As long as you keep only view-related logic in > your rhtml files, they should be very easy for a designer to grok. > > Carl > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- juraci krohling costa
Juca, I''m glad to see one more brazilian coming in. Welcome! There has been some threads in this list discussing the Rails template engine. And although I feel personally comfortable with eRuby (mainly because I don''t have to learn nothing more than just Ruby), I understand the will for plugging in another "cleaner" template language. Ok, bad developers will make bad decisions, like sticking logic code inside the templates, but then, they will make other mistakes somewhere else if they can''t make this one. The bottom line is: Rails provides the helper classes for avoiding this kind of design suicide and in the end, Ruby, with all its power and flexibility, is a language for good developers (for instance, can you imagine bad developers messing with open classes? ouch!). Sometimes, in the attempt to prevent bad practices from bad practioneers (like most Java frameworks do), we make the life of the good practioneers more difficult. And that''s just not good. Anyway, I''m happy you''re here contributing and bringing in some good points for this discusssion. "Um grande abraco", Demetrius Juraci Krohling Costa wrote:>I''m new to ruby/rails and this list, so, i guess that this thread was >already discussed. But what I really don''t understand is why not to do >a template engine (or integrate one). > >I guess that eruby is a jsp-like (asp-like, php-like) template engine. >So, it *should* have the same problems. An example: eruby should be so >powerfull that "bad programmers" (evil exists =D) CAN put their >business logic inside the template. They shouldn''t, but they can. > >Another point: the world isn''t perfect. So, designers generally think >that they should know only design related technologies: html, css, >javascript. Period. >I''ll be very (very) happy when the designers that I work learn all the >template engines that I use. Smarty, Velocity, ZPT, eRuby, Tapestry, >etc... Until that, I must provide them templates that they can edit in >their ***** applications :-) > >But that''s ok. I understand that this feature doesn''t belongs to >rails. Again, what I doesn''t understand is why not to do a template >engine =) > >-- >juca > >On Sat, 12 Feb 2005 10:58:42 -0800, Carl Youngblood <carlwork-0CEYHQKyN7s@public.gmane.org> wrote: > > >>On Feb 12, 2005, at 4:27 AM, Dylan wrote: >> >> >> >>>After a brief look at Zope, I fell in love with ZPT, in fact all my >>>subsequent PHP stuff made use of PHPTal. >>> >>>A TAL implementation for rails would knock people''s socks off! >>> >>> >>David has said before that he deliberately did not want to put a >>template language into rails. After all, eruby is itself a template >>language of sorts and there is no need to waste time creating and >>learning a new one. As long as you keep only view-related logic in >>your rhtml files, they should be very easy for a designer to grok. >> >>Carl >> >>_______________________________________________ >>Rails mailing list >>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>http://lists.rubyonrails.org/mailman/listinfo/rails >> >> >> > > > >
But eruby IS a template language. Adding another would just
slow things down. And rails is so flexible that you could just
create a virtual class to implement whatever templating you
want and then derive your view classes from it.
As far as "bad programmers" go, you touched on a very important
philosophical issue, whether or not to protect programmers from
themselves. There are actually two classes of stupidity to
protect against:
1. simple errors of oversight, e.g. pointer errors, mismatched
declarations (ala C), memory leaks, etc.
2. errors of design, that is, mixing up the architecture and
putting things where they don''t belong.
Protecting against #1 has been one of the primary drivers of
language evolution, and ruby is excellent at preventing those types
of clerical errors.
But #2 is extremely difficult to do with any thoroughness, and
when you try you end up with overly restrictive languages/environments
that cause pain to people who know the rules, but have legitimate
reasons for breaking them occasionally.
Perhaps a practical middle ground would be to document how to
insert templating languages into rails, so that anyone who really
needs a particular templating language can use if they want, while
not bogging down the framework with complexity and increased
execution time.
-Lee
On Sat, 12 Feb 2005 17:37:41 -0200, Juraci Krohling Costa
wrote> I''m new to ruby/rails and this list, so, i guess that this thread
was
> already discussed. But what I really don''t understand is why not
to
> do a template engine (or integrate one).
>
> I guess that eruby is a jsp-like (asp-like, php-like) template
> engine. So, it *should* have the same problems. An example: eruby
> should be so powerfull that "bad programmers" (evil exists =D)
CAN
> put their business logic inside the template. They shouldn''t, but
> they can.
>
> Another point: the world isn''t perfect. So, designers generally
think
> that they should know only design related technologies: html, css,
> javascript. Period.
> I''ll be very (very) happy when the designers that I work learn all
> the template engines that I use. Smarty, Velocity, ZPT, eRuby,
> Tapestry, etc... Until that, I must provide them templates that they
> can edit in their ***** applications :-)
>
> But that''s ok. I understand that this feature doesn''t
belongs to
> rails. Again, what I doesn''t understand is why not to do a
template
> engine =)
>
> --
> juca
>
> On Sat, 12 Feb 2005 10:58:42 -0800, Carl Youngblood
> <carlwork-0CEYHQKyN7s@public.gmane.org> wrote:
> > On Feb 12, 2005, at 4:27 AM, Dylan wrote:
> >
> > > After a brief look at Zope, I fell in love with ZPT, in fact all
my
> > > subsequent PHP stuff made use of PHPTal.
> > >
> > > A TAL implementation for rails would knock people''s
socks off!
> >
> > David has said before that he deliberately did not want to put a
> > template language into rails. After all, eruby is itself a template
> > language of sorts and there is no need to waste time creating and
> > learning a new one. As long as you keep only view-related logic in
> > your rhtml files, they should be very easy for a designer to grok.
> >
> > Carl
> >
> > _______________________________________________
> > Rails mailing list
> > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
>
> --
> juraci krohling costa
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
--
Naxos Technology
On 12 Feb 2005, at 22:20, LN wrote:> As far as "bad programmers" go, you touched on a very important > philosophical issue, whether or not to protect programmers from > themselves.Isn''t it also a question of protecting programmers from bad designers? Guan
On Feb 12, 2005, at 15:16 Uhr, Juraci Krohling Costa wrote:> Hi All, > > This is exactly what I "dislike" in Rails :-)and for me that''s exactly what i love about rails. =) view logic can get quite complicated, if i have to express it in some verbose or awkward language, it''s hell. i ran into enough situations with xml based template languages, where i had to make all kind of weird workarounds just to express some complex view logic. i would agree if ruby would be a very verbose and non-elegant language. but it''s not. so i''m more than happy with it. and like david said, it''s the best if designers work with ''the real thing''. your xml based template might render in dreamweaver.. but how will it look there? will everything be displayed properly? nothing essential omitted? thats a whole different question..
The designers that a lot of the rest of the world works with aren''t the same caliber as 37 signals by a long shot. Dreamweaver expert does not likely yield a decent ruby/rhtml coder... I think some simple JSTL style tags wouldn''t hurt anyone. I imagine the rails community would be excited to get transparent i18n support from a <fmt> style tag rather than put code to look up some sort of localized message bundle on every page. On Sat, 12 Feb 2005 23:02:05 +0100, Florian Weber <csshsh-WuBoz9ku3QfAi70hqydFXw@public.gmane.org> wrote:> > On Feb 12, 2005, at 15:16 Uhr, Juraci Krohling Costa wrote: > > > Hi All, > > > > This is exactly what I "dislike" in Rails :-) > > and for me that''s exactly what i love about rails. =) view logic can > get quite complicated, > if i have to express it in some verbose or awkward language, it''s hell. > i ran into enough > situations with xml based template languages, where i had to make all > kind of weird > workarounds just to express some complex view logic. > > i would agree if ruby would be a very verbose and non-elegant language. > but it''s not. > so i''m more than happy with it. > > and like david said, it''s the best if designers work with ''the real > thing''. your xml based > template might render in dreamweaver.. but how will it look there? will > everything be > displayed properly? nothing essential omitted? thats a whole different > question.. > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On 13.2.2005, at 22:46, Steve Longdo wrote:> The designers that a lot of the rest of the world works with aren''t > the same caliber as 37 signals by a long shot. Dreamweaver expert > does not likely yield a decent ruby/rhtml coder... > > I think some simple JSTL style tags wouldn''t hurt anyone. I imagine > the rails community would be excited to get transparent i18n support > from a <fmt> style tag rather than put code to look up some sort of > localized message bundle on every page.How does this differ from _("some text")? (see http://dev.digitpaint.nl/projects/mll). //jarkko -- Jarkko Laine http://jlaine.net http://odesign.fi _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Feb 13, 2005, at 21:46 Uhr, Steve Longdo wrote:> The designers that a lot of the rest of the world works with aren''t > the same caliber as 37 signals by a long shot. Dreamweaver expert > does not likely yield a decent ruby/rhtml coder...change is possible =) i really think it''s a better idea to get the designer more integrated into the process. otherwise you will end up with ton''s of situations where the designer will ask why something looks different/isn''t displayed/etc. i think it''s better to get the designer work as close to the real thing as possible. that also avoids wasting time.> I think some simple JSTL style tags wouldn''t hurt anyone. I imagine > the rails community would be excited to get transparent i18n support > from a <fmt> style tag rather than put code to look up some sort of > localized message bundle on every page.like jarkko said, whats the difference? what will you do it you need localized text in javascripts, etc?
>> The designers that a lot of the rest of the world works with aren''t >> the same caliber as 37 signals by a long shot. Dreamweaver expert >> does not likely yield a decent ruby/rhtml coder... > > i think it''s better to get the designer work as close to the real thing > as possible. that also avoids wasting time.I concur that its a false dichotomy. The designers at 37signals are not Ruby programmers. What they are capable of is reading english-like code fragments and move them around accordingly. This is how we work: 1. Designer cooks up static HTML template. 2. Programmer sprinkle it with rhtml tags to make the dynamic elements dynamic. 3. Designer and programmer can both revisit the template to make changes. The reason step 3 is possible is exactly what forces good programmer behavior in the templates: <% if @user.is_administrator? %> # show stuff that''s only for administrators <% end %> ...or <% for comment in @post.comments %> <h2><%= comment.headline %></h2> <% end %> No matter how "easy" you make your template language, new dynamic templates are not going to originate from the designers. What you can make possible is cooperation around the same templates once they''re alive. I remain utterly unconvinced that Amrita-style templates are going to do much anything than please the aesthetics that have fallen in love with <li oid="people">Loop</li>. It''s not going to put designers in the driver''s seat for new templates. And even the one promise of being able to edit in Dreamweaver falls to the wayside when you introduce layouts, partials, or other productivity techniques for dealing with templates. The pursuit of "no code"-templates reminds me of the search for the holy grail of the MDA camp with "no code"-programs. It''s mirage, but its also a play on words of the "a rose by any other name..." variety. Code is just another word for decisions about instructions. Whether those decisions are made through indirection and tag decoration, they are still decisions about instructions. That is, its still code. With all that said, I shall not stand in the way for the pursuit of another man''s aesthetic dreams. Many will know that I guide many decisions about Rails from my own sense of aesthetics all the time. I''d feel a lot more at ease about it if the proponents of Amrita-style templates would just confess, or realize (as the true motive may still lie in the subconcious ;)), that the pursuit is one of aesthetics. So. If you want to try this out, feel free. Should a truly non-intrusive solution emerge, I shall even give it serious thought as whether to include it. -- David Heinemeier Hansson, http://www.basecamphq.com/ -- Web-based Project Management http://www.rubyonrails.org/ -- Web-application framework for Ruby http://www.loudthinking.com/ -- Broadcasting Brain
* Steve Longdo <steve.longdo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [0246 20:46]:> The designers that a lot of the rest of the world works with aren''t > the same caliber as 37 signals by a long shot. Dreamweaver expert > does not likely yield a decent ruby/rhtml coder... > > I think some simple JSTL style tags wouldn''t hurt anyone. I imagine > the rails community would be excited to get transparent i18n support > from a <fmt> style tag rather than put code to look up some sort of > localized message bundle on every page.Feh, I could take or leave it myself. If it''s free, then hell yeah, why not? But I''d really rather not have a needlessly restrictive template lib forced on me (that I then have to work around with even uglier code) as the norm. If people want this, surely they could just wrap their more verbose code into a method and have their view call that? -- ''You may need to metaphorically make a deal with the devil. By ''devil'' I mean robot devil and by ''metaphorically'' I mean get your coat.'' -- Bender Rasputin :: Jack of All Trades - Master of Nuns
On Sun, 13 Feb 2005 22:38:16 +0100, David Heinemeier Hansson <david-OiTZALl8rpK0mm7Ywyx6yg@public.gmane.org> wrote:> This is how we work: > > 1. Designer cooks up static HTML template. > 2. Programmer sprinkle it with rhtml tags to make the dynamic elements > dynamic. > 3. Designer and programmer can both revisit the template to make > changes. > > The reason step 3 is possible is exactly what forces good programmer > behavior in the templates: > > <% if @user.is_administrator? %> > # show stuff that''s only for administrators > <% end %> > > ...or > > <% for comment in @post.comments %> > <h2><%= comment.headline %></h2> > <% end %> > > No matter how "easy" you make your template language, new dynamic > templates are not going to originate from the designers. What you can > make possible is cooperation around the same templates once they''re > alive. > > I remain utterly unconvinced that Amrita-style templates are going to > do much anything than please the aesthetics that have fallen in love > with <li oid="people">Loop</li>. It''s not going to put designers in the > driver''s seat for new templates. And even the one promise of being able > to edit in Dreamweaver falls to the wayside when you introduce layouts, > partials, or other productivity techniques for dealing with templates.It''s interesting that you have this opinion, because I''ve actually implemented a language like Amrita (in the dotnet world) recently, hoping that will improve the step (3) that you talk about. It seemed to me that if you allow the designer to make static html with maybe a lot of dummy data to mockup the design, and keep that dummy data in after the page has been made dynamic, that could improve the template''s ability to be round-tripped from designer to developer and back. I do think you''d have to add a "remove" attribute to the Amrita language to support this, though, so the designer could have 50 rows of dummy data and hide 49 of them when it runs dynamically. Your code examples would look like this in the language I wrote: <div ss:if="@user.is_administrator"> <!- stuff that''s only for administrators --> </div> ...or <div ss:foreach="comment in @post.comments"> <h2 ss:var="comment.headline">Some headline lorem ipsum...</h2> <span ss:var="comment.content">Some text ... lorem ipsum dolor ...</span> </div> (I expanded the second example to fit what I think is your intention, printing the comment contents as well eas headline). So, I ask you, if the goal isn''t to put the designer firmly in control or make some revolution, but just to streamline the post-dev roundtripping process, do you still think it''s a terrible idea? I''m not trying to bait you ... I''m just already invested somewhat in this direction and would like to get feedback early. Steve
> With all that said, I shall not stand in the way for the pursuit of > another man''s aesthetic dreams. Many will know that I guide many > decisions about Rails from my own sense of aesthetics all the time. I''d > feel a lot more at ease about it if the proponents of Amrita-style > templates would just confess, or realize (as the true motive may still > lie in the subconcious ;)), that the pursuit is one of aesthetics.it''s totally about aesthetics. well, that and the warm, pleasant feeling of enjoying the code cause it fits my brain exactly how I like it to. (there are many flavors of yogurt available, but I usually tend to only buy those I *really* like). unless it invokes mass confusion, I really don''t see how an additional format for base templates could detract from the greatness that is rails. so now it''s time to wander out and find that non-intrusive solution. ;) Cameron