on 4/17/00 5:55 AM, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
> 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)
The point Stefano is that Turbine is a web application framework. I don't
care about making books or slide shows for the web. I care about doing web
applications because truthfully, that is the cool thing about the web TO ME.
Someone doesn't have to learn how to write a client side application and
it's GUI, they can simply make an unlimited amount of applications that live
in a web browser. Sure it is LCD when it comes to interface (ie: we only
have a small set of widgets to use), but those things will improve.
Using Cocoon to make all my pages look the same and my Back and Next buttons
for me isn't cool to me. These are problems that have been solved before in
many different ways. I want to use Cocoon to make my pages look the same,
make my back/next buttons work AND check out my e-commerce shopping
cart....:-)
I'm also frustrated that Cocoon 2 isn't ready yet. I need that yesterday.
Cocoon 1 most definitely does not hold up in a web application framework
setting (both you and Pier have admitted that). Pushing Cocoon for this type
of role just doesn't make sense right now because it is the wrong tool for
this job _today_. So, for now, I will continue to drudge on with the best
that I have...Webmacro...
> 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.
No it doesn't. Turbine is simply in the M portion of the MVC. It brokers the
request and wraps security and other things around it and then calls the V
to actually display things..
> 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".
I'm sorry Stefano, but this is when I pull my 5 years of experience growing
a 130 person web design shop thing over your head. A lot of designers can
barely do HTML and good javascript experience is a luxury...
:-)
> "yuck" is not a really friendly and neutral metodology of critical
> analisys.
:-)
> 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>
Now, add onto that...
$customSelect.setMultiple(true)
<customSelect multiple=true/>
Personally, I'm betting that the designers will understand the first better
than the second.
Maybe we should have an examples competition and let the designers tell us
what they like best. That would be a much better solution than all of this
guessing and letting the W3C and Justin decide things for us.
:-)
> 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.
Designers don't care about validation or namespacing or transformations.
They care if their selectBox shows up on the screen or not.
:-)
> 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 WM for XML? Huh? I don't know where you are going there...
>> 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... :)
I think it is. I sat down with Federico and Pier on Saturday and explained
Turbine to him in a high level...he gets it and understands how the two can
play together. Lots of other people understand this as well...including
myself.
:-)
-jon
--
Scarab -
Java Servlet Based - Open Source
Bug/Issue Tracking System
<http://scarab.tigris.org/>
--
----------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
