jon * wrote:
<snip>
> I don't see WM as a dead end technology. There are plenty of places where
> people are not going to want to write stuff in XML/XSL/X*. WM is brain dead
> simple and designers (ie: non programmers) "get it".
But the point is that your designers never touch anything but
presentation. Basic XML knowledge and template matching are all that is
needed. A good web GUI designer should be able to handle this. You
give it the schema and simulate content that would match (like search
results in a table, etc).
The developers then code to the protocol and that would be via XML/XSP.
It really is a perfect situation. Sure the implementation is a moving
target and the implemenations (Schema validation, XML/XSL support in the
browsers, etc) but like every good technology it takes time.
> I'm not convinced of
> that yet with X* technologies because they are deadly moving targets. 6-12
> months from now, that probably won't be the case, but for now, that is the
> fact of life. FYI, PHP is not a dead end technology for this exact same
> reason.
:). PERL/PHP/JSP/Webmacro/etc. IMO are all wrong. Time will prove
this. People are feeling it now with applications like Bugzilla that
were written in PERL because the Java solution wasn't that obvious at
the time. Now it is being rewritten in Scarab because of this.
> > Jetspeed is going down this road. There are currently some impl points
> > that Cocoon falls down on. So that is what the point of OSS is that you
> > fix them.
>
> Dude...I'm holding off on Cocoon in Turbine exactly for this reason. I'm
> watching to see what YOU do with Jetspeed. Sorry, but myself and others just
> don't have the time to sit and try and shoot at the moving targets all the
> time. You do. I'm happy about that.
>
> > One of the things I was thinking about was an XHTML -> ECS XSLT
> > stylesheet. So that you write up your UI in XHTML and then it will
> > write out ECS for you. The html2ecs (or whatever is called) is
> > currently now recommended but if you did it in XHTML it wouldn't have
> > any problems and would be within the "correct" and strict domain of
> > XML. The Admin console for Jetspeed is this way sort of. Currently you
> > can dock in any Portlet. Right now they are just basic ECS portlets but
> > this isn't necessary. You could do a Cocoon Portlet too.
>
> Great ideas. Make it happen. ;-)
yup.
"The say time is the fire in which we burn" :(
> > I wanted to see if this model could be integrated into Turbine. The
> > problem is that it relies on Portlets so ... yeah. Regardless I want to
> > see both paths merge some day.
>
> I want to see it into Turbine as well. I wrote that in my paragraph that I
> copy/pasted into my last email. You are the person who is in charge of this
> front because you are the most qualified. Make it happen. ;-)
It would be good if Jetspeed (the core engine at least) could be
small/concise/portable like Cocoon 2.0. This is the path towards 1.3
and hopefully at that point Turbine could use Jetspeed services just
like Webmacro. Then we could share the same Administration console
between apps.
I would like to see the XHTML -> ECS stylesheet happen. It is a fairly
large project but could be bootstrapped with basic elements like html,
body, table, etc.
Kevin
Kevin
--
Kevin A Burton ([EMAIL PROTECTED])
http://relativity.yi.org
Message to SUN: "Please Open Source Java!"
"For evil to win is for good men to do nothing."
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
