Re: [Design] JXTG 2.0 (Just say yes!)
Reinhard Poetz wrote: IIRC we aggreed that we like the current syntax of JXTemplate. Exception: We deprecate the #{} notation in favour of ${xpath:}. If nobody said this already (I have 150 or so mails to go ...), more than one EL per template is clear FS to me. I'd be in favor of specifying EL at the TemplateGenerator declaration time, and would not go more granular than this. Given the above, no need for prefixes (which look ugly to me), and you can always use same syntax. Vadim
Re: [Design] JXTG 2.0 (Just say yes!)
Le 6 déc. 04, à 15:07, Vadim Gritsenko a écrit : Reinhard Poetz wrote: IIRC we aggreed that we like the current syntax of JXTemplate. Exception: We deprecate the #{} notation in favour of ${xpath:}. If nobody said this already (I have 150 or so mails to go ...), more than one EL per template is clear FS to me. I'd be in favor of specifying EL at the TemplateGenerator declaration time, and would not go more granular than this... +1, it might be good to have pluggable languages but run-time switching is definitely FS - and confusing as well. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [Design] JXTG 2.0 (Just say yes!)
On Dec 6, 2004, at 8:14 AM, Bertrand Delacretaz wrote: Le 6 déc. 04, à 15:07, Vadim Gritsenko a écrit : Reinhard Poetz wrote: IIRC we aggreed that we like the current syntax of JXTemplate. Exception: We deprecate the #{} notation in favour of ${xpath:}. If nobody said this already (I have 150 or so mails to go ...), more than one EL per template is clear FS to me. I'd be in favor of specifying EL at the TemplateGenerator declaration time, and would not go more granular than this... +1, it might be good to have pluggable languages but run-time switching is definitely FS - and confusing as well. Thank you. Think this approach is applicable to the tag vs. attribute debate? Glen Ezkovich HardBop Consulting glen at hard-bop.com http://www.hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: [Design] JXTG 2.0 (Just say yes!)
Le 6 déc. 04, à 15:41, Glen Ezkovich a écrit : On Dec 6, 2004, at 8:14 AM, Bertrand Delacretaz wrote: Le 6 déc. 04, à 15:07, Vadim Gritsenko a écrit : Reinhard Poetz wrote: IIRC we aggreed that we like the current syntax of JXTemplate. Exception: We deprecate the #{} notation in favour of ${xpath:}. If nobody said this already (I have 150 or so mails to go ...), more than one EL per template is clear FS to me. I'd be in favor of specifying EL at the TemplateGenerator declaration time, and would not go more granular than this... +1, it might be good to have pluggable languages but run-time switching is definitely FS - and confusing as well. Thank you. Think this approach is applicable to the tag vs. attribute debate? Sure. Having mixed languages or mixed tag/attributes templating mechanisms in the same template sounds equally confusing. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [Design] JXTG 2.0 (Just say yes!)
Daniel Fagerstrom wrote: Bertrand Delacretaz wrote: Le 6 déc. 04, à 15:41, Glen Ezkovich a écrit : On Dec 6, 2004, at 8:14 AM, Bertrand Delacretaz wrote: Le 6 déc. 04, à 15:07, Vadim Gritsenko a écrit : Reinhard Poetz wrote: IIRC we aggreed that we like the current syntax of JXTemplate. Exception: We deprecate the #{} notation in favour of ${xpath:}. If nobody said this already (I have 150 or so mails to go ...), more than one EL per template is clear FS to me. I'd be in favor of specifying EL at the TemplateGenerator declaration time, and would not go more granular than this... +1, it might be good to have pluggable languages but run-time switching is definitely FS - and confusing as well. Thank you. Think this approach is applicable to the tag vs. attribute debate? Sure. Having mixed languages or mixed tag/attributes templating mechanisms in the same template sounds equally confusing. What about being able to mix Groovy's XML sytax with the the ordinary one, wouldn't that be nice ;) Ring! Ring! Ring! (Stefano's FS alarm bells) :-) Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Design] JXTG 2.0 (Just say yes!)
On Dec 6, 2004, at 8:49 AM, Bertrand Delacretaz wrote: Le 6 déc. 04, à 15:41, Glen Ezkovich a écrit : On Dec 6, 2004, at 8:14 AM, Bertrand Delacretaz wrote: Le 6 déc. 04, à 15:07, Vadim Gritsenko a écrit : Reinhard Poetz wrote: IIRC we aggreed that we like the current syntax of JXTemplate. Exception: We deprecate the #{} notation in favour of ${xpath:}. If nobody said this already (I have 150 or so mails to go ...), more than one EL per template is clear FS to me. I'd be in favor of specifying EL at the TemplateGenerator declaration time, and would not go more granular than this... +1, it might be good to have pluggable languages but run-time switching is definitely FS - and confusing as well. Thank you. Think this approach is applicable to the tag vs. attribute debate? Sure. Having mixed languages or mixed tag/attributes templating mechanisms in the same template sounds equally confusing. LOL. It did seem obvious to me. Should never have phrased it as a question. I think this might also work in other ways as well. Considering the heat of the taglib debate (where, I think a lot of misunderstanding occurred on both sides), this might be able to get the benefits of using a taglib like approach to the implementation of template generators/transformers. Same basic component gets a tag/attribute library evaluator (excuse the phrase, brain freeze occurred concerning the proper term ... or maybe I got it right ;-)). Seems that this way the only difference between a JXTG and a SQLTG would be the way they were configured in the sitemap and the library they were configured to use. The approach could be flexible enough to allow any combination to be configured, allowing those who think they have such a use case, to commit virtual suicide. Saner minds can do their best to prevent abuse by threatening immediate termination upon such egregious configuration of components. ;-) Glen Ezkovich HardBop Consulting glen at hard-bop.com http://www.hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: [Design] JXTG 2.0 (Just say yes!)
Sylvain Wallez wrote: Vadim Gritsenko wrote: Reinhard Poetz wrote: IIRC we aggreed that we like the current syntax of JXTemplate. Exception: We deprecate the #{} notation in favour of ${xpath:}. If nobody said this already (I have 150 or so mails to go ...), Yeah, cocoon-dev has gone crazy during the week-end :-) more than one EL per template is clear FS to me. I'd be in favor of specifying EL at the TemplateGenerator declaration time, and would not go more granular than this. I don't agree: it happens quite often to have mixed view data combining java objects and XML. In that case, a single EL is just painful. It just says a lot about state of the art in the expression language arena but does not demonstrate a need for more than one! :) Furthermore, specifying the language in the component declaration doesn't help readability nor reuse of templates between projects. If you don't see any better way out, I'd go as far as allowing to choose EL in template itself, using attribute on the root element. I'd not go further, though. Vadim
Re: [Design] JXTG 2.0 (Just say yes!)
On Dec 6, 2004, at 9:00 AM, Sylvain Wallez wrote: Reinhard Poetz wrote: Yeah, cocoon-dev has gone crazy during the week-end :-) more than one EL per template is clear FS to me. I'd be in favor of specifying EL at the TemplateGenerator declaration time, and would not go more granular than this. I don't agree: it happens quite often to have mixed view data combining java objects and XML. Hmmm... why does this happen? It seems that the java could be injected by by one component and the XML by another. In that case, a single EL is just painful. Furthermore, specifying the language in the component declaration doesn't help readability nor reuse of templates between projects. Readability of what, the sitemap or the template. Frankly, while it adds complexity to the sitemap, it only does so for template generators/transformers. I think understandability will be more affected by naming choices then the configuration complexity. Only needing to interpret a single EL in a template undoubtedly improves readability. Imagine me writing this using french, polish and english phrases randomly interspersed. I don't see how this affects reusability. Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Glen Ezkovich HardBop Consulting glen at hard-bop.com http://www.hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: [Design] JXTG 2.0 (Just say yes!)
On Monday 06 December 2004 23:00, Sylvain Wallez wrote: In that case, a single EL is just painful. Furthermore, specifying the language in the component declaration doesn't help readability nor reuse of templates between projects. Is it only me? I like Java a lot, and how come I can't construct the page parts in Java as well? Is it that people really love to learn 15 different programming languages when one can do more than enough? Tapestry, IMHO, have got a lot of things right. Let the programmers use Java and let the designers use Dreamweaver (or whatever their personal choice is). Having the programmers crank out some tr statements isn't that much of a deal, but blurring the pitcure of who is in charge of the template is. The designer knows shit-all about any programming construct and the programmer knows shit-all about design (pardon my french). Maybe this community is a lot about people who think that they are in the middle and can do both... no offense :o) , most real-world projects are not organized in that manner. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+
Re: [Design] JXTG 2.0 (Just say yes!)
Bertrand Delacretaz wrote: Le 6 déc. 04, à 15:57, Daniel Fagerstrom a écrit : ...What about being able to mix Groovy's XML sytax with the the ordinary one, wouldn't that be nice ;) (you just forgot to add the sound of Stefano's FS detector exploding in the background) ROTFL I love you guys :-) -- Stefano.
Re: [Design] JXTG 2.0 (Just say yes!)
Niclas Hedhman wrote: On Monday 06 December 2004 23:00, Sylvain Wallez wrote: In that case, a single EL is just painful. Furthermore, specifying the language in the component declaration doesn't help readability nor reuse of templates between projects. Is it only me? I like Java a lot, and how come I can't construct the page parts in Java as well? Is it that people really love to learn 15 different programming languages when one can do more than enough? Tapestry, IMHO, have got a lot of things right. Let the programmers use Java and let the designers use Dreamweaver (or whatever their personal choice is). Having the programmers crank out some tr statements isn't that much of a deal, but blurring the pitcure of who is in charge of the template is. The designer knows shit-all about any programming construct and the programmer knows shit-all about design (pardon my french). Well, I for one hate writing tons of Java to build a screen, despite being a Java developer since JDK 1.1.x. A screen is a declarative thing to me, and the natural language to build it is some kind of XML. Furthermore, I want to organize it as I want, without having to ask a webdesigner to change the location of a button. That's why I love templates that produce structural layout markup (e.g. html with classes) that is styled down the pipeline by various transformations and CSS. Maybe this community is a lot about people who think that they are in the middle and can do both... no offense :o) , most real-world projects are not organized in that manner. Be careful: the concept of real-world project is a highly varying concept here :-) Tapestry provides only one way to do things, meaning its users have to accept this way or switch to another framework. Cocoon is at the other end by providing so many ways of doing things that there cannot be a single imposed way. Like it or not, that part of what makes Cocoon so special and used in so many different contexts. And the kilometer-long thread on JXTG 2.0 clearly shows this :-) Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Design] JXTG 2.0 (Just say yes!)
Glen Ezkovich wrote: On Dec 6, 2004, at 9:00 AM, Sylvain Wallez wrote: Reinhard Poetz wrote: Yeah, cocoon-dev has gone crazy during the week-end :-) more than one EL per template is clear FS to me. I'd be in favor of specifying EL at the TemplateGenerator declaration time, and would not go more granular than this. I don't agree: it happens quite often to have mixed view data combining java objects and XML. Hmmm... why does this happen? It seems that the java could be injected by by one component and the XML by another. Not always, e.g. when you have an XML document and objects describing its metadata which are both managed by a flowscript. In that case, a single EL is just painful. Furthermore, specifying the language in the component declaration doesn't help readability nor reuse of templates between projects. Readability of what, the sitemap or the template. Reusability of the template, since you don't know just by reading the template source file what EL was used to write it. Frankly, while it adds complexity to the sitemap, it only does so for template generators/transformers. I think understandability will be more affected by naming choices then the configuration complexity. Only needing to interpret a single EL in a template undoubtedly improves readability. Imagine me writing this using french, polish and english phrases randomly interspersed. Well, if you omit polish, this is no problem for me :-) And if each phrase is prefixes with the language name, making the mental switch between ELs (or realizing that I must learn polish) is not a problem. I don't see how this affects reusability. Yes it does, since moving templates around require to be sure that the component they're processed with is configured for the right expression language. Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Design] JXTG 2.0 (Just say yes!)
On Dec 6, 2004, at 3:32 PM, Sylvain Wallez wrote: Hmmm... why does this happen? It seems that the java could be injected by by one component and the XML by another. Not always, e.g. when you have an XML document and objects describing its metadata which are both managed by a flowscript. I did think about this and a few other similar cases. Because we are considering template generation and template transformation it would be possible to use the metadata to construct the template that will be used by the transformer. I'm not sure I like this, but that is one of the ideas that has been mentioned. Also I think its possible for one expression language to be used to work with both Java and XML using appropriate syntax. It seems that something like ${/abc/def/ghi} and ${myObject.myMethod();} could coexist in a single EL. What would need to be invalid are expressions like ${/abc/def/myobject.myMethod()}. I'm not sure I like it. Its not completely aesthetically pleasing but it is better then document(@href)/*/node(). ;-) (maybe it is possible to use the current XPath and Jexl implementations and just do some syntax validation up front) Readability of what, the sitemap or the template. Reusability of the template, since you don't know just by reading the template source file what EL was used to write it. So you are saying that if you have two expression languages its going to be easier ;-) As it is, you know that it is either XPath or Jexl. Well, that is assuming you are using JXTG. If you are not, what EL is being used? If you can understand it I think you'd have a pretty good idea what the EL was. This like saying if you pick up an novel in english you can't tell what language is used. Granted multiple expression languages can have similar syntaxes and be semantically different. Wouldn't it be odd (and wonderful) if templates written in one would produce correct but totally different results in the other. Talk about reusability. Not that I think this would happen. My point is, if it makes sense, then you probably know what EL is being used. If you are wrong and it still works correctly, who cares. :P Frankly, while it adds complexity to the sitemap, it only does so for template generators/transformers. I think understandability will be more affected by naming choices then the configuration complexity. Only needing to interpret a single EL in a template undoubtedly improves readability. Imagine me writing this using french, polish and english phrases randomly interspersed. Well, if you omit polish, this is no problem for me :-) Maybe not the best example :-) It's usually not a problem for me either when I know that multiple languages are used. Syntactically, two or more ELs could be quite similar and thus hard to always know which you are reading. I really don't have a problem with the fact that someone wants to use two or more ELs in the same template. I can see use cases where having two, three or more ELs available could be a very useful thing. I also think with the ability to generate a template, these use cases will become fewer. And if each phrase is prefixes with the language name, making the mental switch between ELs (or realizing that I must learn polish) is not a problem. No its not. However, one of the things I have learned over the years is that not everyone is capable of making context switches quickly. I do believe that if you wish to use multiple ELs, you should be able to... by configuring your component to do so. I just would like to prevent my team from doing so unless no acceptable alternative exists. I don't see how this affects reusability. Yes it does, since moving templates around require to be sure that the component they're processed with is configured for the right expression language. I agree. But the same is true with any component. This is where documentation and testing come in. I think the out of the box cocoon should be as simple as possible. When you are at the point of having your metadata in java objects and your data in XML I would think that 15 minutes to configure a generator or transformer would be a worth while investment of your time. I don't see how things are damaged that much by having to configure your components in the sitemap. I know XPer's believe that the documentation is the code and Cocooners tend to hate writing doc comments. For both the constraints and power of configurable components I don't think its to much to ask of your template designers to list the ELs used in the template in some comments. Now after all this, I'm going to take the advice of the subject line and just say YES. Refactor JXTG. Then 90% of the battle will be won by us all. I think all of this is tangential to the real task at hand. Clean elegant code makes me happy. Didn't all this start with an effort to stabilize CForms? Its been so long I forget. Glen Ezkovich HardBop Consulting glen at hard-bop.com
Re: [Design] JXTG 2.0 (Just say yes!)
Sylvain Wallez wrote: Vadim Gritsenko wrote: Sylvain Wallez wrote: ... Furthermore, specifying the language in the component declaration doesn't help readability nor reuse of templates between projects. If you don't see any better way out, I'd go as far as allowing to choose EL in template itself, using attribute on the root element. I'd not go further, though. Mmmh... like XSP does... BTW, isn't it you that added Python and JavaScript support to XSP? ;-) But... But... But see, I had never suggested to use several languages in the same page, at once! :-P Vadim
Re: [Design] JXTG 2.0 (Just say yes!)
On Tue, 2004-12-07 at 00:45 +0100, Jonas Ekstedt wrote: On Mon, 2004-12-06 at 22:32 +0100, Sylvain Wallez wrote: Glen Ezkovich wrote: On Dec 6, 2004, at 9:00 AM, Sylvain Wallez wrote: Reinhard Poetz wrote: Yeah, cocoon-dev has gone crazy during the week-end :-) more than one EL per template is clear FS to me. I'd be in favor of specifying EL at the TemplateGenerator declaration time, and would not go more granular than this. I don't agree: it happens quite often to have mixed view data combining java objects and XML. Hmmm... why does this happen? It seems that the java could be injected by by one component and the XML by another. Not always, e.g. when you have an XML document and objects describing its metadata which are both managed by a flowscript. Fully agree. Restricting expressions to only one type would be quite bad I think. In addition to xpath and jelly it would also be cool with formatting expressions (ie ${format:jelly-expression#type}). As an example of all three types (xpath, jelly and format) consider a site with some articles and a calendar on it: body pYour last login: ${format:user.lastLogin#short}/p h3This months calendar/h3 calendar:month currentDate=${jelly:today}/ h3Articles/h3 dom:out select=${xpath:/domVariable/articles/article} /body Cheers Jonas Oops! jelly - jexl // jonas
Re: [Design] JXTG 2.0 (Just say yes!)
On Dec 4, 2004, at 8:19 AM, Daniel Fagerstrom wrote: With that said, a usable taglib-driven system already exists. Jelly. If you need taglibs, go with that. No need to re-invent something different in cocoon. Both I and Carsten have tried to use Jelly in Cocoon but the fit isn't that good. See our posts in http://marc.theaimsgroup.com/?t=10993268021r=1w=2. Ah, I missed that thread :) I have Jelly working pretty well in Cocoon. You can modify the JellyContext to take a Source object and use that to create the template. And the templates are thread-safe, its just that each template invocation will require a new JellyContext object. There are a few edges where usages of URL could be replaced with Source, but not that many. The implementation is just a few adapter classes and works great! I'm happy to share with anyone interested in pursuing this further. -pete
Re: [Design] JXTG 2.0 (Just say yes!)
peter royal wrote: On Dec 4, 2004, at 8:19 AM, Daniel Fagerstrom wrote: With that said, a usable taglib-driven system already exists. Jelly. If you need taglibs, go with that. No need to re-invent something different in cocoon. Both I and Carsten have tried to use Jelly in Cocoon but the fit isn't that good. See our posts in http://marc.theaimsgroup.com/?t=10993268021r=1w=2. Ah, I missed that thread :) I have Jelly working pretty well in Cocoon. You can modify the JellyContext to take a Source object and use that to create the template. And the templates are thread-safe, its just that each template invocation will require a new JellyContext object. There are a few edges where usages of URL could be replaced with Source, but not that many. The implementation is just a few adapter classes and works great! I'm happy to share with anyone interested in pursuing this further. -pete Thanks for your offer, but I've joined the NIH camp, so its to late for me ;) Furthermore, Jelly doesn't seem like such an active project anymore. The script compilation is just a part of the project, factoring out and solidifying contracts for expression handling and other stuff is at least as important. To me it just didn't seem worthwhile enough to fight with Jelly's interfaces and implementation to get it to do what I wanted. And it also takes time and engagement to convince another community about adopting your suggestions. I mean its hard enough for me in the Cocoon community ;) And also you know what we Cocooners think about basing our core stuff on others code ;) /Daniel
Re: [Design] JXTG 2.0 (Just say yes!)
peter royal wrote: On Dec 2, 2004, at 4:47 PM, Stefano Mazzocchi wrote: Sure, that's a better syntax, but the fundamental problem remains: template designers don't know nothing about SQL, nor care, nor know anything about request parameters, not know anything about dynamic tags nor know how to debug something in case somebody screws up with the order of those tags! taglibs are *very* useful for applications. a programmer (that may or may not have knowledge of how to use tags) can construct a form using a tag library. the constructed document can then be rendered to multiple mediums.. rich browser UI, static PDF, tables to XLS, simple HTML for handhelds. the template designer just creates one master template for each output medium. a programmer actually writes the implementation of that template. With that said, a usable taglib-driven system already exists. Jelly. If you need taglibs, go with that. No need to re-invent something different in cocoon. Both I and Carsten have tried to use Jelly in Cocoon but the fit isn't that good. See our posts in http://marc.theaimsgroup.com/?t=10993268021r=1w=2. /Daniel
Re: [Design] JXTG 2.0 (Just say yes!)
Jonas Ekstedt wrote: I think the reason for taglibs are that rendering an object is often more complicated than simply outputting a value. For example, suppose you want to render a calendar covering the current month. This is a typical component that would lend itself well as a tag class. The template writer would simply do: calendar:month current-date=${myDate}/ The tag might output something like this: month value=2 week value=12 day value=5 name=Monday/ day value=6 name=Tuesday current=true/ day value=7 name=Wednesday/ ... /week ... /month Later transformations would transform it into a table or whatever. This type of calendar would be very hard to do for a template author without the help of a tag library. I have completely no time these days so I was just waiting for the single post to say: Cannot agree more here :) The current discussion about taglibs have focused very much on esql and whether SQL belongs in templates or not. I agree that SQL in templates are a bad idea, but that is really beside the point in regards to the virtues of taglibs. Exactly. Everyone concentrated on ESQL as a taglib while this is the WORST example there is. ESQL does a lot of persistence logic and can have enormous side effects. Taglibs should have no side effects at all. Taglibs (in my view) are primarily about converting objects to SAX. Here are a few ideas for taglibs that only deals with presentation of objects (as opposed to esql which also populates). * Bean renderers jx:set var=ignored value=${Packages.com.something.DateUtil.emitPrettyDate( bean.startDate, cocoon.consumer/ - is this one better than the taglib? Or should I implement a stylesheet that would parse my 100kB xml file just to look for dateutils:prettydate value=2003-01-01/ ? * DOM renderers * ResultSet renderers (ie renders a query made in flow) * Menus * Page navigation * Tabs (similar to tabs in CForm) * CForm tags * cinclude * Calendars (showing week, month etc.) * wiki renderers currently I do something like to parse wiki syntax: function radeoxToSAX( str, consumer ) { var radeoxStr = radeoxEngine.render( str, radeoxContext ); var buffer = new java.lang.StringBuffer(root ); buffer.append( radeoxStr ) buffer.append( /root ); var is = new Packages.org.xml.sax.InputSource( new java.io.StringReader( buffer.toString() ) ); var parser = null; var includeConsumer = new org.apache.cocoon.xml.IncludeXMLConsumer( consumer, consumer ); includeConsumer.setIgnoreRootElement( true ); try { parser = cocoon.getComponent( Packages.org.apache.excalibur.xml.sax.SAXParser.ROLE ); parser.parse( is, includeConsumer ); } finally { if ( parser != null ) cocoon.releaseComponent( parser ); } } jx:macro name=radeox-string jx:parameter name=value/ jx:set var=ignored value=${cocoon.session.radeox( value, cocoon.consumer )}/ /jx:macro snip/ radeox-string value=${project.description}/ This clearly is a hack and should be implemented as taglib. * ValueList renderers a taglib that supports displaying a narrowed list of values, searchable, paginable and so on The items above are in my view better examples of the benefits of taglibs. They're all about how to render an object. The object is populated in flow but how to render it is implemented in the tag classes. Maybe we should stop using taglib word. What we're trying to do may simply be harmed by the emotions that this phrase carries. Sure all taglibs/convertors/renderers could be implemented as stylesheets or custom transformers. But creating a pipeline with 15 transformations (which by the way mainly would do identity transformations and expand only specific tags) is neither performant nor elegant. In case of custom transformers it's also never easy. -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [Design] JXTG 2.0 (Just say yes!)
On Dec 2, 2004, at 4:47 PM, Stefano Mazzocchi wrote: Sure, that's a better syntax, but the fundamental problem remains: template designers don't know nothing about SQL, nor care, nor know anything about request parameters, not know anything about dynamic tags nor know how to debug something in case somebody screws up with the order of those tags! taglibs are *very* useful for applications. a programmer (that may or may not have knowledge of how to use tags) can construct a form using a tag library. the constructed document can then be rendered to multiple mediums.. rich browser UI, static PDF, tables to XLS, simple HTML for handhelds. the template designer just creates one master template for each output medium. a programmer actually writes the implementation of that template. With that said, a usable taglib-driven system already exists. Jelly. If you need taglibs, go with that. No need to re-invent something different in cocoon. For document-centric production, sure, what's your fighting against is totally valid. But taglibs have their place too (even if the idea may be used in inappropriate places) -pete
Re: [Design] JXTG 2.0 (Just say yes!)
Stefano Mazzocchi wrote: Daniel Fagerstrom wrote: Stefano Mazzocchi wrote: Let me re-iterate: there have for a long time been a concesus at the list among those who have cared enough to discuss it that JXTG is a well working way of creating views, but that the implementation is very hard to maintain. Fair enough. A template language has nothing to do with taglibs, per se. There has also been an agreement about that ESQL is the only reason (besides back compability) to care about XSP, you said so youself a week ago or so. After using it for a little while, I changed my mind. :-) Ok For those of us who use CForms it is very convenient to be able to use the template tags together with JXTG constructs. I believe the best template system does not use tags at all. It either uses content (as in velocity) or it uses attributes (as in tapestry). In our previous discussion at the list our conclusion was that JXTG is ok and that although there might be slightly better approaches or ideas in one way or another, the general feeling was that it would be better to evolve from JXTG than to do something completely different. We must protect our users investments in Cocoon technology. Of course we should do new and revolutionary stuff when we find a much better way of doing things. But that something is slightly better is not a good enough reason, IMO. Having said that, I'm happy to keep the template framework open enough to make it possible to plug in an attribute driven approach or parsers for content driven approaches. It should be quite easy to do that AFAIK. Now, these are no itches that I have, but if you or some one else come upp with a design proposal for such a template language, I can take part in adapting the framework for it. snip/ In the general case I would rather write just the query with some surrounding tags like in the SQLTransformer, get a simple standardized XML serialization of the row set and then transform it to HTML in XSLT. That works only for trivial monolythic cases. For any serious reporting application (for example, where order is parameter dependable) that doesn't work. I assumed the context of the having both SQL and JX tags in the generator step, then you can do serious reporting. I even happen to know that, as I and my coleagues have done serious repporting in numerous applications for a number of years in that way. The only difference compared to the SQLTransformer would be that I can combine it with JXTG constructions and insert query params in a convinient way. This is exactly the point that makes me say just say no to taglibs because, as I explained before, no matter what syntax, putting query parameters in a SQL string is not something that should be in a template! Ok, I start to realize that you assume that I suggest that everything should be done in the template step. No I don't, I do what you refer to as the controler concern, i.e. put together and execute the SQL query based on request params in the template. All view related stuff is done in the next step, typically XSLT. snip/ Sure, that's a better syntax, but the fundamental problem remains: template designers don't know nothing about SQL, nor care, nor know anything about request parameters, not know anything about dynamic tags nor know how to debug something in case somebody screws up with the order of those tags! let me rewrite the above: controller.script: var query = SELECT name,description + FROM projects + WHERE project= + request.id + ORDER BY name ; var results = cocoon.datasources.gump.execute(query); request.context.set(projects,results); view.template (content style): ul #foreach project in projects lia href=projects?name=${project.name}${project.name}/a - ${project.description}/li #end /ul or view.template (attribute style): ul x:foreach=project in projects lia href=projects?name=${project.name}${project.name}/a - ${project.description}/li /ul note how SoC also allows you to use a different technology (example, O/R or straight OODBMS or even RDF triple stores!) to populate the beans without the template designers know anything about this! What I want is something like this: - request comes - sitemap gets it - matcher matches - controller is executed and populates beans in the request context - pipeline is invoqued with access to the request context - response goes Now, this can happen right now in flow and JXtemplate. If we don't need state management, this is just like having a better action model with XSP-like code recompilation. Concerning SoC I agree completely, It is a good idea to separate the query composition and execution from the result set rendering, I have always done it that way and have never recomended anyone to mix them. Concerning writing code for query composition and execution in an action variant of flowscript I also agree :), I think that its better than doing
Re: [Design] JXTG 2.0 (Just say yes!)
Reinhard Poetz wrote: Stefano Mazzocchi wrote: One concern is to come up with a unified template language. This implies: 1) understanding the features we want (and we don't want!) from a template language 2) come up with a syntax 3) implement it Another and completely separate concern is how to factor out existing bits so that #3 is easier. You are attacking #3 before attacking #1 and #2 and that's why everybody here is feeling frustration: there is no consensus on #1 I don't think so. There were tons of mails and IMHO we agreed on a list of features (maybe a final summary is missing) I would be very helpful if we could agree on the above two points with a vote (and a summary, of course) before moving on. -- Stefano.
Re: [Design] JXTG 2.0 (Just say yes!)
Leszek Gawron wrote: Jonas Ekstedt wrote: I think the reason for taglibs are that rendering an object is often more complicated than simply outputting a value. For example, suppose you want to render a calendar covering the current month. This is a typical component that would lend itself well as a tag class. The template writer would simply do: calendar:month current-date=${myDate}/ The tag might output something like this: month value=2 week value=12 day value=5 name=Monday/ day value=6 name=Tuesday current=true/ day value=7 name=Wednesday/ ... /week ... /month Later transformations would transform it into a table or whatever. This type of calendar would be very hard to do for a template author without the help of a tag library. I have completely no time these days so I was just waiting for the single post to say: Cannot agree more here :) I cannot disagree more. ${myDate as month} will do the above without mentioning tags (and will be much more Dreamweaver-friendly). The current discussion about taglibs have focused very much on esql and whether SQL belongs in templates or not. I agree that SQL in templates are a bad idea, but that is really beside the point in regards to the virtues of taglibs. Exactly. Everyone concentrated on ESQL as a taglib while this is the WORST example there is. ESQL does a lot of persistence logic and can have enormous side effects. Taglibs should have no side effects at all. excuse me? what side effect does a SELECT have? Taglibs (in my view) are primarily about converting objects to SAX. If this is the case, then taglib is a *VERY BAD* name. I agree that some objects might be sax-ified differently, depending on user needs, but the name taglibs makes the syntactic and the semantic concern overlap and annoys people (like me) that ended up hating dynamic XML tags after promoting them for so long. Here are a few ideas for taglibs that only deals with presentation of objects (as opposed to esql which also populates). * Bean renderers jx:set var=ignored value=${Packages.com.something.DateUtil.emitPrettyDate( bean.startDate, cocoon.consumer/ - is this one better than the taglib? Or should I implement a stylesheet that would parse my 100kB xml file just to look for dateutils:prettydate value=2003-01-01/ ? I completely agree that the transformation stage is overkill, that's not my point. I think that better than both you can do ${bean.startDate as -MM-DD} * DOM renderers excuse me? * ResultSet renderers (ie renders a query made in flow) are you kidding? regular iteration is all you need. * Menus * Page navigation * Tabs (similar to tabs in CForm) what? * CForm tags the above ${var as flavor} will do * cinclude no way * Calendars (showing week, month etc.) see above * wiki renderers currently I do something like to parse wiki syntax: function radeoxToSAX( str, consumer ) { var radeoxStr = radeoxEngine.render( str, radeoxContext ); var buffer = new java.lang.StringBuffer(root ); buffer.append( radeoxStr ) buffer.append( /root ); var is = new Packages.org.xml.sax.InputSource( new java.io.StringReader( buffer.toString() ) ); var parser = null; var includeConsumer = new org.apache.cocoon.xml.IncludeXMLConsumer( consumer, consumer ); includeConsumer.setIgnoreRootElement( true ); try { parser = cocoon.getComponent( Packages.org.apache.excalibur.xml.sax.SAXParser.ROLE ); parser.parse( is, includeConsumer );} finally { if ( parser != null ) cocoon.releaseComponent( parser ); } } jx:macro name=radeox-string jx:parameter name=value/ jx:set var=ignored value=${cocoon.session.radeox( value, cocoon.consumer )}/ /jx:macro OH COME ON! you can do a generator and cinclude a subpipeline for that. snip/ radeox-string value=${project.description}/ This clearly is a hack and should be implemented as taglib. You will have to step on my dead body before that's the case. * ValueList renderers a taglib that supports displaying a narrowed list of values, searchable, paginable and so on The items above are in my view better examples of the benefits of taglibs. They're all about how to render an object. The object is populated in flow but how to render it is implemented in the tag classes. Maybe we should stop using taglib word. What we're trying to do may simply be harmed by the emotions that this phrase carries. No matter what you call it, if you want to have dynamic XML tags, you will hurt yourself, your wiki example is the kind of things that gives me the creeps. -- Stefano.
Re: [Design] JXTG 2.0 (Just say yes!)
Stefano Mazzocchi wrote: Leszek Gawron wrote: Jonas Ekstedt wrote: I think the reason for taglibs are that rendering an object is often more complicated than simply outputting a value. For example, suppose you want to render a calendar covering the current month. This is a typical component that would lend itself well as a tag class. The template writer would simply do: calendar:month current-date=${myDate}/ The tag might output something like this: month value=2 week value=12 day value=5 name=Monday/ day value=6 name=Tuesday current=true/ day value=7 name=Wednesday/ ... /week ... /month Later transformations would transform it into a table or whatever. This type of calendar would be very hard to do for a template author without the help of a tag library. I have completely no time these days so I was just waiting for the single post to say: Cannot agree more here :) I cannot disagree more. ${myDate as month} will do the above without mentioning tags (and will be much more Dreamweaver-friendly). Hehe, this is exactly what I outlined in my What do we need taglibs for? post. The fight is merely about tags vs brace-expansion syntax, but not about the underlying feature. snip/ * wiki renderers currently I do something like to parse wiki syntax: function radeoxToSAX( str, consumer ) { var radeoxStr = radeoxEngine.render( str, radeoxContext ); var buffer = new java.lang.StringBuffer(root ); buffer.append( radeoxStr ) buffer.append( /root ); var is = new Packages.org.xml.sax.InputSource( new java.io.StringReader( buffer.toString() ) ); var parser = null; var includeConsumer = new org.apache.cocoon.xml.IncludeXMLConsumer( consumer, consumer ); includeConsumer.setIgnoreRootElement( true ); try { parser = cocoon.getComponent( Packages.org.apache.excalibur.xml.sax.SAXParser.ROLE ); parser.parse( is, includeConsumer );} finally { if ( parser != null ) cocoon.releaseComponent( parser ); } } jx:macro name=radeox-string jx:parameter name=value/ jx:set var=ignored value=${cocoon.session.radeox( value, cocoon.consumer )}/ /jx:macro OH COME ON! you can do a generator and cinclude a subpipeline for that. Or ${wikistring as radeox} :-) Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Design] JXTG 2.0 (Just say yes!)
Stefano Mazzocchi wrote: snip/ I would be very helpful if we could agree on the above two points with a vote (and a summary, of course) before moving on. Stefano, Unstable blocks doesn't need a vote, and the template one is the result of unusually extensive mail discussions and also on a general agrement about the direction. Everything is in the mail-archives and I and others have written numerous summaries with vast references to the relevant writings. If you care to check the archives you can see that I and others had all reasons to believe that we did something that was agreed about and wanted by the community. Obviously we don't have an agreement anymore and I'm not going to start any vote about anything until we have found a solution that we can agree about again. Neither will I continue any design or implementation activities in the template area until we can find a constructive way out of this. What I have proposed should be rather clear from my writings and it is quite distant from what I'm accused to propose in your and others reactions. Anyway, I'll wait for your and other critics constructive stated alternatives. An emmotinally over heated crusade against things that neither I or anyone else has proposed will not lead us anywhere. I'll urge you and others that have constructive ideas about what we should do in the templating area to post your ideas. And please focus on what you want rather then what you hate. I'll be happy to continue my involvement in finding, designing and implementing a good template solution that we as a community feel happy about after that. /Daniel
Re: [Design] JXTG 2.0 (Just say yes!)
Stefano Mazzocchi wrote: Leszek Gawron wrote: Jonas Ekstedt wrote: I think the reason for taglibs are that rendering an object is often more complicated than simply outputting a value. For example, suppose you want to render a calendar covering the current month. This is a typical component that would lend itself well as a tag class. The template writer would simply do: calendar:month current-date=${myDate}/ The tag might output something like this: month value=2 week value=12 day value=5 name=Monday/ day value=6 name=Tuesday current=true/ day value=7 name=Wednesday/ ... /week ... /month Later transformations would transform it into a table or whatever. This type of calendar would be very hard to do for a template author without the help of a tag library. I have completely no time these days so I was just waiting for the single post to say: Cannot agree more here :) I cannot disagree more. ${myDate as month} will do the above without mentioning tags (and will be much more Dreamweaver-friendly). Sure - but - isn't this only a change at syntax level?. You are describing a convertor here - something that has been discussed a few threads before and what Jonas implemented as #{myDate#full}. The current discussion about taglibs have focused very much on esql and whether SQL belongs in templates or not. I agree that SQL in templates are a bad idea, but that is really beside the point in regards to the virtues of taglibs. Exactly. Everyone concentrated on ESQL as a taglib while this is the WORST example there is. ESQL does a lot of persistence logic and can have enormous side effects. Taglibs should have no side effects at all. excuse me? what side effect does a SELECT have? these: esql:queryinsert into task values ( something, something ); select @@identity/esqu:query still a select from template point of view. Taglibs (in my view) are primarily about converting objects to SAX. If this is the case, then taglib is a *VERY BAD* name. I agree that This mainly is the case. At least for me. some objects might be sax-ified differently, depending on user needs, but the name taglibs makes the syntactic and the semantic concern overlap and annoys people (like me) that ended up hating dynamic XML tags after promoting them for so long. Here are a few ideas for taglibs that only deals with presentation of objects (as opposed to esql which also populates). * Bean renderers jx:set var=ignored value=${Packages.com.something.DateUtil.emitPrettyDate( bean.startDate, cocoon.consumer/ - is this one better than the taglib? Or should I implement a stylesheet that would parse my 100kB xml file just to look for dateutils:prettydate value=2003-01-01/ ? I completely agree that the transformation stage is overkill, that's not my point. I think that better than both you can do ${bean.startDate as -MM-DD} Sure. Still I would like to render my date specially if the date is before some point in time. My syntax would be: dateutils:pretty-enhanced-date value=${bean.startDate} turning-point=2004-01-01/ This way I can achieve same formatting across the whole project. * DOM renderers excuse me? not going to defent examples that I did not give. Jonas? :) * ResultSet renderers (ie renders a query made in flow) are you kidding? regular iteration is all you need. agree here * Menus * Page navigation * Tabs (similar to tabs in CForm) what? Jooonas? :)) * wiki renderers currently I do something like to parse wiki syntax: function radeoxToSAX( str, consumer ) { var radeoxStr = radeoxEngine.render( str, radeoxContext ); var buffer = new java.lang.StringBuffer(root ); buffer.append( radeoxStr ) buffer.append( /root ); var is = new Packages.org.xml.sax.InputSource( new java.io.StringReader( buffer.toString() ) ); var parser = null; var includeConsumer = new org.apache.cocoon.xml.IncludeXMLConsumer( consumer, consumer ); includeConsumer.setIgnoreRootElement( true ); try { parser = cocoon.getComponent( Packages.org.apache.excalibur.xml.sax.SAXParser.ROLE ); parser.parse( is, includeConsumer );} finally { if ( parser != null ) cocoon.releaseComponent( parser ); } } jx:macro name=radeox-string jx:parameter name=value/ jx:set var=ignored value=${cocoon.session.radeox( value, cocoon.consumer )}/ /jx:macro OH COME ON! you can do a generator and cinclude a subpipeline for that. OH COME ON! :) Transformation to pretty print a date is an overkill. CInclude for string pretty printing is not? Moreover imagine you have a simple table: | project name | project description | there are 100 rows out of which every description is wikified. that means 1 generator for the template and 1 for each description. Total 101 generators invoked. Neat. snip/ radeox-string value=${project.description}/ This clearly is a hack and should be implemented as taglib. You will have to
Re: [Design] JXTG 2.0 (Just say yes!)
Leszek Gawron wrote: Stefano Mazzocchi wrote: ${bean.startDate as -MM-DD} Sure. Still I would like to render my date specially if the date is before some point in time. My syntax would be: dateutils:pretty-enhanced-date value=${bean.startDate} turning-point=2004-01-01/ This way I can achieve same formatting across the whole project. In the replying-to-hard-topic-stress(tm) I forgot about the question: How would you pass additional parameters? Or maybe you are considering it harmful? -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [Design] JXTG 2.0 (Just say yes!)
Stefano Mazzocchi wrote: Let me re-iterate: there have for a long time been a concesus at the list among those who have cared enough to discuss it that JXTG is a well working way of creating views, but that the implementation is very hard to maintain. There has also been an agreement about that ESQL is the only reason (besides back compability) to care about XSP, you said so youself a week ago or so. For those of us who use CForms it is very convenient to be able to use the template tags together with JXTG constructs. So we need a template generator with three sets of tags jx:, esql: and ft: thats it. We also discused how to use a separate conversion layer to remove the need for formating constructs from the template layer. --- o0o --- Given these general requirements that have been discussed again and again at the list and also some more technical, performance driven requirments, I steped forward and proposed a possible way of implementing it. This design is based on a rather far going SoC in the interest of keeping it maintainable. We have also identified a number of templateing components that are needed in other places in Cocoon. E.g. expression language and object model and therefore are worth implementing as separate components. I also proposed implementing the three sets of tags discussed above as taglibs instead of making their interpretation being part of a huge monolitic SAX event handler as in JXTG. Implementing it that way it is must easier to write test code for the tags and generally easier to understand what is going on. --- o0o --- Given this background, I was quite suprised when Miles Elam whent ballistic about that I mentioned the word taglib and draw conclsions about my intensions that are far and in several cases oposite from what I feel and have written anything about. Anyway, if you have better suggestions about how to solve the above requirements I'm all ears. --- o0o --- Now over to commenting what you have written. So, my other side thinks that having a scripted controller invoquing different templated views is a better solution. In this case, do we need taglibs at all? no we don't. esql:queryselect * from blah/esql:query sounds easy enough, but in real life it's more something like esql:connection esql:poolgump/esql:pool esql:execute-query esql:query SELECT name,description FROM projects ORDER BY name /esql:query esql:results esql:row-results li axsp:attribute name=hrefprojects?name=esql:get-string column=name//xsp:attributeesql:get-string column=name//a - esql:get-string column=description/ /li /esql:row-results /esql:results /esql:execute-query /esql:connection and *THIS IS THE SIMPLES QUERY I CAN THINK OF*!!! In the general case I would rather write just the query with some surrounding tags like in the SQLTransformer, get a simple standardized XML serialization of the row set and then transform it to HTML in XSLT. The only difference compared to the SQLTransformer would be that I can combine it with JXTG constructions and insert query params in a convinient way. If I would like to do everything in one step as you suggest above it might look more like: esql:connection esql:poolgump/esql:pool esql:execute-query esql:query SELECT name,description FROM projects WHERE projectleader=${cocoon.request-param.id}ORDER BY name /esql:query esql:results esql:row-results li a href=projects?name=${$row.name}/${$row.name}/a - ${$row.description} /li /esql:row-results /esql:results /esql:execute-query /esql:connection As we are using the same kind of expression template mechanisms as in JXTG. We could probably make the syntax more efficient and take away some of the tag layers if we feel like that. What I want is something like this: - request comes - sitemap gets it - matcher matches - controller is executed and populates beans in the request context - pipeline is invoqued with access to the request context - response goes Now, this can happen right now in flow and JXtemplate. If we don't need state management, this is just like having a better action model with XSP-like code recompilation. Sure, I agree with all that. Only question is: where do I put my SQL queries in the above scenario? But the whole point of this discussion is: do we need taglibs? I'm sorry, but I agree with Miles, we don't: all we need is a velocity/garbage-like template system and recompilable java controllers. If you by this mean that you don't see any need in writing special purpose taglibs as a typical part of normal webapp development, I couldn't agree more. Everything else is making a step backwards. As said above my only purpose
Re: [Design] JXTG 2.0 (Just say yes!)
Daniel Fagerstrom wrote: Stefano Mazzocchi wrote: Let me re-iterate: there have for a long time been a concesus at the list among those who have cared enough to discuss it that JXTG is a well working way of creating views, but that the implementation is very hard to maintain. Fair enough. A template language has nothing to do with taglibs, per se. There has also been an agreement about that ESQL is the only reason (besides back compability) to care about XSP, you said so youself a week ago or so. After using it for a little while, I changed my mind. :-) For those of us who use CForms it is very convenient to be able to use the template tags together with JXTG constructs. I believe the best template system does not use tags at all. It either uses content (as in velocity) or it uses attributes (as in tapestry). So we need a template generator with three sets of tags jx:, esql: and ft: thats it. I disagree, we don't need a set of tags *AT ALL*. We also discused how to use a separate conversion layer to remove the need for formating constructs from the template layer. --- o0o --- Given these general requirements that have been discussed again and again at the list and also some more technical, performance driven requirments, I steped forward and proposed a possible way of implementing it. This design is based on a rather far going SoC in the interest of keeping it maintainable. We have also identified a number of templateing components that are needed in other places in Cocoon. E.g. expression language and object model and therefore are worth implementing as separate components. I also proposed implementing the three sets of tags discussed above as taglibs instead of making their interpretation being part of a huge monolitic SAX event handler as in JXTG. Implementing it that way it is must easier to write test code for the tags and generally easier to understand what is going on. Very well, you just picked the wrong name: a refactoring of common services into reusable components has nothing to do with enforcing the use of tags into a template language. But more on this later. --- o0o --- Given this background, I was quite suprised when Miles Elam whent ballistic about that I mentioned the word taglib and draw conclsions about my intensions that are far and in several cases oposite from what I feel and have written anything about. keep reading and you might understand why. Anyway, if you have better suggestions about how to solve the above requirements I'm all ears. Here I am. --- o0o --- Now over to commenting what you have written. Bring it on :-) So, my other side thinks that having a scripted controller invoquing different templated views is a better solution. In this case, do we need taglibs at all? no we don't. esql:queryselect * from blah/esql:query sounds easy enough, but in real life it's more something like esql:connection esql:poolgump/esql:pool esql:execute-query esql:query SELECT name,description FROM projects ORDER BY name /esql:query esql:results esql:row-results li axsp:attribute name=hrefprojects?name=esql:get-string column=name//xsp:attributeesql:get-string column=name//a - esql:get-string column=description/ /li /esql:row-results /esql:results /esql:execute-query /esql:connection and *THIS IS THE SIMPLES QUERY I CAN THINK OF*!!! In the general case I would rather write just the query with some surrounding tags like in the SQLTransformer, get a simple standardized XML serialization of the row set and then transform it to HTML in XSLT. That works only for trivial monolythic cases. For any serious reporting application (for example, where order is parameter dependable) that doesn't work. The only difference compared to the SQLTransformer would be that I can combine it with JXTG constructions and insert query params in a convinient way. This is exactly the point that makes me say just say no to taglibs because, as I explained before, no matter what syntax, putting query parameters in a SQL string is not something that should be in a template! If I would like to do everything in one step as you suggest above it might look more like: esql:connection esql:poolgump/esql:pool esql:execute-query esql:query SELECT name,description FROM projects WHERE projectleader=${cocoon.request-param.id}ORDER BY name /esql:query esql:results esql:row-results li a href=projects?name=${$row.name}/${$row.name}/a - ${$row.description} /li /esql:row-results /esql:results /esql:execute-query /esql:connection As we are using the same kind of expression template mechanisms as in JXTG. We could probably make the syntax more efficient and take away some
Re: [Design] JXTG 2.0 (Just say yes!)
Stefano Mazzocchi wrote: One concern is to come up with a unified template language. This implies: 1) understanding the features we want (and we don't want!) from a template language 2) come up with a syntax 3) implement it Another and completely separate concern is how to factor out existing bits so that #3 is easier. You are attacking #3 before attacking #1 and #2 and that's why everybody here is feeling frustration: there is no consensus on #1 I don't think so. There were tons of mails and IMHO we agreed on a list of features (maybe a final summary is missing) and #2 so IIRC we aggreed that we like the current syntax of JXTemplate. Exception: We deprecate the #{} notation in favour of ${xpath:}. attacking #3 now is more harmful than useful. hmmm, IMO #1 and #2 was done ... -- Reinhard
Re: [Design] JXTG 2.0 (Just say yes!)
Stefano Mazzocchi wrote: The only difference compared to the SQLTransformer would be that I can combine it with JXTG constructions and insert query params in a convinient way. This is exactly the point that makes me say just say no to taglibs because, as I explained before, no matter what syntax, putting query parameters in a SQL string is not something that should be in a template! Thank you. Sure, that's a better syntax, but the fundamental problem remains: template designers don't know nothing about SQL, nor care, nor know anything about request parameters, not know anything about dynamic tags nor know how to debug something in case somebody screws up with the order of those tags! let me rewrite the above: controller.script: var query = SELECT name,description + FROM projects + WHERE project= + request.id + ORDER BY name ; var results = cocoon.datasources.gump.execute(query); request.context.set(projects,results); view.template (content style): ul #foreach project in projects lia href=projects?name=${project.name}${project.name}/a - ${project.description}/li #end /ul or view.template (attribute style): ul x:foreach=project in projects lia href=projects?name=${project.name}${project.name}/a - ${project.description}/li /ul note how SoC also allows you to use a different technology (example, O/R or straight OODBMS or even RDF triple stores!) to populate the beans without the template designers know anything about this! Thank you! If this isn't a case study of what to do with simple queries, I don't know what is. Personally I like: ul x:test=projects li x:context=projectsa href=projects?name=${name}${name}/a - ${description}/li /ul Where each item in projects becomes the reference scope. ;-) If there are no projects, no list tags are written. But then, I'm one of those weird guys who doesn't mind seeing things like ${.} occasionally to refer to the current iterated item. I also have to admit a love for test conditionals that don't require the explicit != null grammar. Hey! We can all dream, right? One concern though: Is that results variable a result set or just a collection of data. If the former, how is the database connection handled (closing or returning to the pool)? If the latter, how can large result sets be returned without exhausting memory from a few queries? That's the one case where I see ESQL winning out. All other cases where you aren't dumping the contents of a table, this seems like an excellent idea. If a web developer can't handle that much scripting, what chance do they have with an ESQL taglib? Sure, I agree with all that. Only question is: where do I put my SQL queries in the above scenario? this is the whole stinking point: *never* in the template! Thank you. But the whole point of this discussion is: do we need taglibs? I'm sorry, but I agree with Miles, we don't: all we need is a velocity/garbage-like template system and recompilable java controllers. If you by this mean that you don't see any need in writing special purpose taglibs as a typical part of normal webapp development, I couldn't agree more. No, not only that: I think that the person responsible for doing writing the logic that drives the flow *and* the content population of the page is *NOT* the same person that does the design of the template. Thank you. - Miles Elam
RE: [Design] JXTG 2.0 (Just say yes!)
Miles wrote: One concern though: Is that results variable a result set or just a collection of data. If the former, how is the database connection handled (closing or returning to the pool)? If the latter, how can large result sets be returned without exhausting memory from a few queries? That's the one case where I see ESQL winning out. Surely the controller script should handle this too? After calling the template it should clean up the model.
Re: [Design] JXTG 2.0 (Just say yes!)
On Thu, 2004-12-02 at 16:47 -0500, Stefano Mazzocchi wrote: snip... In both cases, they are suboptimal from what I wrote above, where content population and content presentation are kept completely isolated and the only contract between the two is: 1) the shape of the objects in the context 2) how to perform simple variable espansion, list iteration and conditioning. #2 is the only thing that should be exposed to a template language (just like velocity does), everything else should be dealt with at the view population level. Which is going to be code, written by coders and people that deal a lot better with code than with anything else. I think the reason for taglibs are that rendering an object is often more complicated than simply outputting a value. For example, suppose you want to render a calendar covering the current month. This is a typical component that would lend itself well as a tag class. The template writer would simply do: calendar:month current-date=${myDate}/ The tag might output something like this: month value=2 week value=12 day value=5 name=Monday/ day value=6 name=Tuesday current=true/ day value=7 name=Wednesday/ ... /week ... /month Later transformations would transform it into a table or whatever. This type of calendar would be very hard to do for a template author without the help of a tag library. The current discussion about taglibs have focused very much on esql and whether SQL belongs in templates or not. I agree that SQL in templates are a bad idea, but that is really beside the point in regards to the virtues of taglibs. Taglibs (in my view) are primarily about converting objects to SAX. Here are a few ideas for taglibs that only deals with presentation of objects (as opposed to esql which also populates). * Bean renderers * DOM renderers * ResultSet renderers (ie renders a query made in flow) * Menus * Page navigation * Tabs (similar to tabs in CForm) * CForm tags * cinclude * Calendars (showing week, month etc.) The items above are in my view better examples of the benefits of taglibs. They're all about how to render an object. The object is populated in flow but how to render it is implemented in the tag classes. Cheers Jonas
Re: [Design] JXTG 2.0 (Just say yes!)
I was working on an extremely long e-mail about this but Torsten, Stefano and a repentant Miles covered most of my points. Thanks for the help and for allowing me to waste my time :-P However... It seems that you are trying to do more then just replace the current functionality JXTG. You want to include the possibility processing the kitchen sink. I think this is what's bothering many of us. This will lead to breaking the separation of concerns. While implementing this in a template may seem better then implementing it in an XSP, in the end I suspect it will be just as ugly. The only thing that will change is the syntax. Semantically, it will be just as ugly. There is already too much power in the existing JXTG. On the other hand, I find the idea of a general template generator intriguing. I think you might be on to something, but I think you are missing it. Ok so you want a replacement for JXTG, create a tag library and have the template generator use it. You want the functionality of ESQL without XSP, create a tag library for it. Want to process CSVs, write a tag library for it. Want to process excel spreadsheets, create a tag library. The problem is that generally you declare the libraries in the document in which they are used and can use as many libraries as you want. This is where the evil part of tag libs comes in. It allows you to do anything and everything in one place. No separation of concerns can be enforced. View, controller, model all can be intermingled. Suppose, that instead of allowing all Tag Libraries to be used by the generator, each generator could only use one library. That is JXTG could only process JXTG tags, SQLTG could only process ESQL tags, ExcelTG could only process EXCEL tags, etc. TemplateGenerator is a perfect candidate for an abstract class. Each subclass just needs to have a Tag Library with which to work. This makes it much easier to implement other template generators just implement a new Tag Library and some constructors. Of course nothing prevents someone from adding multiple libraries to their generator should they choose to do so. They can deal with the consequences. This gives you the flexibility in design you want. It gives you the functionality that you want, since it is unlikely that you will want to access java objects and then access a database. It also helps limit the abuse that tag libraries can engender. Just my 0.02 . Now if I could just come up with a way to keep all html tags out of the JX templates. Glen Ezkovich HardBop Consulting glen at hard-bop.com http://www.hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow