From: Florian Weber Date: 2004-07-26T16:37:53+09:00 Subject: Re: rubyonrails and cgikit comparison hi kirk! basically i see the same problem in your first example. you have presentation logic (knowing about css) in your application layer. i like the idea of having a special file with such stuff ('MyPage_layout.rb') though. thats basically how you can do it in rails also. you can just define a little view helper file where you can define such methods, so you dont have to do really dirty stuff in the eruby file directly. basically i think the problem is: at some point presentation logic (which css class to use) and business data (not business logic!) meet (is @some_stuff > 3). cgikits approach is to access the business data in the application layer, to calculate more complicatied presentation logic with it there and to simple provide a way to pick up that presentation logic from the view. basically without ever referencing directly to the business data.. i think the difference with rails is that its allowed to access business data directly from within the template. the thing is though: you can, you dont have to.. you could also do stuff like: foo you can just use a little template helper method to define the @linkcolor property.. i'm very interested in other approaches though. like i said, i'm highly sceptical about pure-xml views. i think its often overseen that views can be complex and have complicated business logic in them. but just because one part of the view is xhtml, doesnt mean that we also have to use xml for parts where real programming languages would be much better. i mean after all there is also stuff like javascript.. like i said though, im very interested in other approaches. especially one of the different link color based on different business data problem, solved with a xml templating language using conditions.. >> foo >> >> how would you do this in xml? > > I'm finding this discussion fascinating as a discussion of different > approaches to solving a problem. This particular example intrigued me > a bit > as while I personally don't like the above sort of mixing of code into > HTML, > I also found that the CGIKit method of dealing with this that Raphael > posted > to be more a more roundabout solution that I like, as well. > > Here's Iowa's take on the above: > > HTML file: > > foo > > > Code file: > > def linkcolor > @some_stuff > 3 ? 'red' : 'black' > end > > > Now, my approach to this would, if I were planning ahead, would > probably be > to use a CSS class instead of setting the style directly. That way > all I > really end up doing is toggling between two different class names, and > I let > the decision on what effect that has on the link's appearance be > determined > in the stylesheet. > > HTML: > > foo > > > Code: > > def linkclass > @some_stuff > 3 ? 'link_error' : 'link_normal' > end > > > CSS: > > .link_error {color: red} > .link_normal {color: black} > > > Either way we are calling a piece of code from the HTML, but the code > is not > actually embedded in there. If one is working in the > designer/developer > segregation model, one can either not let the designers write any code > at > all with this seperation, or if one trusts one's designers to write > code > like linkclass() themselves, one could structure the code so that > while the > main code file is the repository for the business logic for the page, > and is > the domain of the developer, it require's a seperate code file that the > designers can use that contains presentation logic that will be used > in the > template. Something like: > > > class MyPage < Iowa::Component > > require 'MyPage_layout.rb' # This is the presentation logic file > > # Everything else is business logic for the page. > # . > # . > # . > end > > > Anyway, glad to see your Rails release come to fruition, David. Keep > up the > good discussions. They are very interesting.