jon * wrote:
> No. I downloaded it, played with all the examples and spent at least 5 hours
> with it. Can you say the same thing about Turbine?
point :) (but I tried hard to make it run!) I'm trying again in a couple
of days.
> > Maybe you should go get http://www.eurofootball.com... then tell me: is
> > this a slideshow? is this a book?
>
> No. It is a pretty website (just like a slideshow and a book is a pretty
> presentation). It isn't a web application.
Given your statement, you're right. But the line is thin, don't you
agree?
> > Ok, sorry, I'm probably stupid, but you are saying that javascript
> > experience is a luxury... but WebMacro experience is not? You are saying
> > that people that are used to tags and work with them all day long, find
> > easier a syntax that doesn't have anything to do with tags?
> >
> > Are you kidding?
>
> It has been proven that it is possible to teach a page designer who knows
> NOTHING about Java and nothing about XML or XSLT how to simply put a
> $selectorBox in their HTML where they want to display something. The
> designers "get it". I'm not so sure that designers will get Cocoon as easily
> because even I have a hard time with it (maybe I'm an idiot...I don't know).
No, you're absolutely right there. XML is a pain in the ass. Powerful,
awesome but it has the steeper learning curve ever for web technologies.
But I'm secretly working on something that would change that :) (at
least, I hope!)
> In a web application, EVERY screen is different, even the navigation is
> different. That doesn't apply very well when dealing with XML and
> transformations because you end up with a bazillion different
> transformations every time. It is just to complicated to manage all that
> stuff when you can do it with Turbine/Webmacro and it is brain dead
> simple...
Agreed. The problem is that you can invert the sentence and still holds
true :)
This is why we need integration.
> >> 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.
> >
> > And I don't :)
>
> So, lets just agree to disagree. :-)
+1
> >> 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.
> >
> > This is no competition.
>
> Why? Because your way (or the W3C way) is the only right way?
Absolutely not. I was just indicating that since Turbine and Cocoon do
not overlap, how can there possibly be competition? I was concerned
about integration issues.
> Give me a break Mr. Gates... :-)
>
> (Yes, I do know your pressure points. <smile>)
Nah, they slowly oved over the years :)
> >> Designers don't care about validation or namespacing or transformations.
> >
> > They don't now, because they have no ideas of what they are for (like
> > most of the people, anyway).
>
> Nor do they care to know. I'm like them...I don't want to have to learn XSLT
> just to design a web page. Looking at the spec and some of the example
> documentation it is totally overwhelming. I want something that it brain
> dead simple.
I share your vision. But sometimes you just need more than stupid HTML.
> > Of course. Validation would tell you if it runs on the screen without
> > even trying it :)
>
> In a web application doing that is generally impossible to do in the real
> world because what you did 5 screens previously matters on the screen that
> you are working on now. It makes it really hard to do validation on stuff
> like that.
True, can get very hard. But just like Java has interfaces, XML has
schemas.
> > I was thinking about integration with Turbine and Cocoon... and webmacro
> > for XML doesn't work that great...
>
> Actually, they can work hand in hand. You can do a model like this:
>
> Turbine->Webmacro
> ->Cocoon
>
> In other words...Turbine brokers the request...calls Webmacro to build the
> body and dynamic navigation portions of the page and then passes that to
> Cocoon to do the transformation and rendering.
Cocoon is not a transformation engine and there is no way it can
possible work "after" Turbine. Rather it should go the other way around:
request -> Cocoon -> skeleton pages -> turbine components -> structured
page -> transformed page
> >> 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.
> >
> > Well, please take the time to enlighten me, then. :)
>
> The same things that you and I talked about at ApacheCon. We can make it so
> that Turbine calls Cocoon or that Cocoon calls Turbine. Not a big deal at
> all. Kevin has already done a lot of Turbine/Cocoon integration as well.
> This stuff is possible and not that difficult. We have Java to thank for a
> lot of that.
I'll try to dive deeper.
--
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]
