jon * wrote:
> Turbine doesn't have these problems and also has a lot of "helper" code to
> make this stuff easy. The end goal for Turbine is to be that bridge that
> makes it easy for designers and developers to work together. The beauty of
> Turbine is that each time someone comes up with a new page template
> language, Turbine can be easily adopted to work with it. Right now, Turbine
> works with Cocoon, Freemarker, Webmacro and has initial support for JSP, but
> it hasn't been finished for obvious reasons. Essentially, the "View" portion
> of Turbine is pluggable. How cool is that?
Not very to me.
Such general pluggability hurts because imposes "least common
denominator" hooks. When Turbine uses Cocoon as a renderer is going to
waste most of its capabilities. Cocoon is not only a rendering library
(even if, of course, it includes one)
Instead, integrating the two would mean that you can "markup" a turbine
module using an XML namespace so that non-programmers can manipulate
them more easily (sort of taglib, sort of what tapestry is doing),
without polluting the general programming-centric view of web
applications.
> > Tapestry has components to handle forms and form elements just as
> > gracefully. It's HTML might look something like:
> >
> > <p>Select from the following:
> > <jwc id="select">
> > <jwc id="e">
> > <jwc id="option"/>
> > </jwc>
> > </jwc>
> >
> > You would then supply a specification for select, e and option. select
> > provides the <SELECT> element. e will be an enum component, that will pull
> > an array, Vector or Enumeration from your application (via a parameter
> > binding) and enumerate its contents. These object will likely by business
> > objects of some form defined by the application.
>
> No offense, but I find that syntax ugly and VERY hard to read and not "View"
> at all. On top of it, you now have to teach a designer how to write some
> funky XML markup language that you invented out of thin air...
>
> If you use WM and Turbine's SelectorBox module, it is simply:
>
> <p>Select from the following:
> $selectBox
>
> Now, you tell me which one is easier to teach to designers and entry level
> engineers...:-)
It depends, as everything. In my humble experience, designers have
_much_ less troubles in understanding markup that orthogonal syntax.
Moreover, markup it's much more "GUI-friendly".
> > option will extract a property from the current business object as the label
> > for an <OPTION> element. option components have a read/write 'selected'
> > property that can be bound to some JavaBeans property of the business object
> > .... the selected property is read when the HTML page is generated and
> > updated when the form on the page is submitted.
>
> Yuck.
"yuck" is not a really friendly and neutral metodology of critical
analisys.
> > If you find in your application that you are building this option list in
> > multiple places (with the same business objects and so forth), you can use
> > aggregation to create a code-less component (that is, the existing class
> > com.primix.tapestry.BaseComponent provides the code and doesn't need to be
> > extended). Then your HTML template will look like:
> >
> > <p>Select from the following:
> > <jwc id="customSelect"/>
>
> Yuck. Coldfusion sucks for this very reason. Do you really believe that you
> will be able to get designers to write this stuff?
Totally!
Coldfusion is bad because you have a predefined (huge!) set of elements,
no notion of namespaces and no notion of programmatic markup
tranformations. JSP taglibs will have the exact same problems.
Now, open your mind and tell me the difference between:
<p>Select from the following: $customSelect</p>
<p>Select from the following: <customSelect/></p>
it's pretty much identical. Except the XML parser will skip the first
one and ignore it. WebMacro is _intentionally_ orthogonal. But doing
that, you loose _everything_ you have in the XML world: structure
validation, namespacing, trasformations. WebMacro was created by someone
that came from the SGML world and you can clearly tell.
I agree with you that WebMacro makes perfect sense in an HTML
environment where you don't have much help from the language model
anyway. But using WebMacro for XML? to me, it makes absolutely no sense.
> Using Turbine + Webmacro gets you the same thing that you are talking about
> above and you don't have to write some non standard XML markup...on top of
> it if you DO want to write XML markup into your pages, you have the option
> to integrate Turbine with Cocoon which implements W3C standards.
I wish it was that easy... :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
--
----------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
