burtonator wrote:
>
>>>Reptile does this... and does a lot more.
>>>
>>Show me. Where's the live demo ?
>>
>
> Right now I haven't focused on building a client-server demo. Reptile can
> certainly support this but it is not our focus. Right now Reptile is basically
> a P2P application which you run locally.
>
> You can either look at the screenshots or download the build and run
> "reptile-startup.sh"
>
OK, so Reptile does not answer the same need that Jetspeed but try to create
a new usage paradigm using P2P.
>
>>>>This is completely bogus: Programming has always been the art of manipulating
>>>>and transforming data using deterministic algorithms. XML just introduces a
>>>>new standard and very flexible syntax for manipulating data. It does not change
>>>>in any way the need for processing data which can be expressed in any programming
>>>>language you care to use.
>>>>
>>>>
>>>No. I believe you misunderstand. The problem is with the Jetspeed API you end
>>>up spending all your time working with Java. With Reptile, use of Java is
>>>deprecated and XML is what is most important.
>>>Careful what you say. It obviously isn't "completely" bogus because Reptile is
>>>doing it right now. ;)
>>>
>>>
>>It just means you embed code in your transformation step, ans partly delegate
>>processing to XPath selector in XSL styling. This is messy and unmanageable
>>just like those great 1-line regular expressions hack in Perl.
>>
>
> You are certainly entitled to your opinion. I think it is a narrow view though.
>
Time and usage will tell.
>>>>>Jetspeed could not function without the Portlet API. This is especially true
>>>>>because a lot of Jetspeed's own UI is generated with Portlets. Reptile handles
>>>>>this problem with Xalan extensions. This also has the added advantage of
>>>>>providing Reptile with a plugin architecture which supports other languages
>>>>>besides Java including Python, Javascript, etc due to the IBM Bean Scripting
>>>>>framework.
>>>>>
>>>>>
>>>>>
>>>>You mean you want to handle programming logic within XSL stylesheets ?
>>>>
>>>>
>>>No. Most of the complex logic is done via XSLT extension functions. Example:
>>><xsl:value select="extension:someReallyComplexJavaFunction()"/>
>>>
>
>
>>Yeah, worse. Mixing XPath, XSL and scripts is IMO a kind of engineering
>>perversion.
>>
>
> And... why? There is nothing different with this approach when compared to
> Velocity, JSP, etc.
>
Granted for JSP. The whole point of Turbine/Velocity is to properly separate
what should be the realm of the developer and what should be the realm of the
designer (using MVC pattern). The same can be said of Cocoon which specifically
tries to enforce separation of content between teams of different skills.
If you don't see why it's different from your approach, then I think you'll
soon find out in a couple of months when you'll try to incorporate new ideas
in Reptile or if you ever try to explain and train people to use your Product.
>
>>All these tools are great when used in their proper context, but mixing them
>>all in just FS all the way (FS: flexibility syndrome, for those who don't know
>>what it's about check the Cocoon archives...).
>>
>
> Let me put it this way. I believe that I have made more progress with Reptile
> than my entire time I worked with Jetspeed.
>
Fair enough.
>
> You disagree that choice is good! OK.
>
> Reptile as an engine will stick to 100% Java. Users/admins can write anything
> they want. This is where choice comes in.
>
Yes, I disagree that choice is good by nature. There are some cases where it's
sensible to provide choice and some where it just leads to unnecessary
complications and does not provide real benefits.
>> > >>>Another main difference is that there is no PSML. Instead we use a system
>>
>>>>>of layout, control and page schemas which can produce the same output but in
>>>>>a much more flexible manner. > >
>>>>>
>>>>Probably, a lot of systems are more flexible than PSML, the catch is to keep
>>>>enouch power while still offering user customization capabilities.
>>>>
>>>>
>>>The exact same power is available with our approach and with a lot more
>>>flexibilty.
>>>
>>
>>Give us some details then, I'd love to know how you handle user
>>controlled customization.
>>
>
> Sure.
>
> Essentially we start with an XML layout file. This file contains content
> positioning information:
>
> <content location="resource:/xml/users/default/news.rss"
> contentType="http://purl.org/rss/1.0/";>
>
> <position column="left" layer="Home"/>
>
> </content>
>
> In order to change the position of this file within the Portal all we setup a
> new control which reads this position information (all via XSLT) and provides a
> quick HTML form layout.
>
> The user then selects right or left and the column he wants to have this control
> on. After that we invoke an action on the server (similar to the way Turbine
> handles actions) and invoke a short XSLT to make any changes and then serialize
> the output into the source XML file.
>
> When the user goes back to the page after the post everything is taken care of.
>
OK. Just 2 things:
- the basic approach is the same than PSML or Cocoon aggregation
- you have hard-coded your layout policy choice (left/right/layer) in
your customizer choice. If you want to add a new column, you must rewrite
a customizer; if you want to allow the user to edit the layer colors, yet
another rewrite; if you want to edit a WML layout, yet another rewrite...
> This would be a *really* ugly mess if it was done in Java. You would have to
> write a SAX/DOM hack which reads in the content and serializes it to XML. With
> a stylesheet we can do this in about 4 lines of functional code and 20 lines for
> the whole file.
>
Except that doing this is Java can also abstract you from the persistence
mechanism and can provide you with caching capabilities, transactional security,
etc...
>
>>What you mean is because Jetspeed offers functionalities that can't be reproduced
>>under Reptile, they are not relevant ?
>>
>
> There is no plugin API under Reptile. Content is generated via XSLT sequence
> system. If you want to add a plugin, lets say that runs a search of a database,
> you would right a Xalan extension and collect the output from the search.
>
> stylesheet1.xsl (connect to database via java extensions when given a
> 'search-query' param>
>
> OUTPUT:
>
> <search-result>
>
> <entry>Foo</entry>
> <entry>Bar</entry>
>
> </search-result>
>
> stylesheet2-xsl (handles providing device specificy rendering of this content)
>
> <dc:title>My Jetspeed plugin analogy</dc:title>
>
> <control:body>
>
> Found the following results:
>
> 1. Foo<br/>
>
> 2. Bar<br/>
>
> </control:body>
>
> This is for "plugin" content. The rest of Reptile will apply a controller.xsl,
> control.xsl and a page.xsl which provides the necessary UI to for the whole
> page.
>
Yeah, I've discussed this extensively at last ApacheCon Europe with Ingo's team
and XO3 people, and I think this is a very appealing solution; however proper
implementation of this is quite involved if you want your system to support
arbitrary source DTD and your data source to be rendered in arbitrary output
format.
Right right, reptile seems to assume the administrator control other all the
stylesheets and DTD.
>
>>Come on, Kevin, drop the marketing hat, we're engineers around here if you have
>>nice, compelling ideas just explain them and we'll evaluate and compare. If you
>>don't have something tangible, just let us work and preach elsewhere.
>>
>
> Does the above not work for you?
> <snip>
>
Not as such, I need separation of concern in order to break responsabilities
between different members of a team.
>>Disregarding, such a stable, industrial strength serving environment because
>>you currently only needed 10% of the functionalities and you could implement
>>that easily is either lazyness (you did not want to learn how to use cocoon)
>>or lack of foresight (you can't imagine that you'll need the rest of the
>>functionalities some day).
>>
>
> It just boils down to math. The Reptile stylesheet framework is 3 .java files.
> Maybe 50 - 60 functional lines of code. It does what we need it to do and it
> does so very well IMO.
>
> ... nuf said.
>
Yes, I understand. It's a development taylored to your need, not a product.
> Again. I like Cocoon and I *certainly* have no problems with it. Cocoon just
> needs to just itself just like every other technology in the world.
>
> Sorry... I fail to believe that a solution is correct just because it comes from
> Apache.
>
Agreed there, but to make an analogy, I still find strange that people start
writing crappy lite HTTP servers when they could just embed the well-tested,
efficient and supported Apache httpd and customize to their need...
>
>>In both case, I have strong doubts on the evolution of Reptile as a project,
>>especially given your track record in Jetspeed.
>>
>
> hm... my track record huh? Jetspeed wouldn't even exist without my "track
> record".
>
It also would have died.
> Regardless of your doubts, I believe that Reptile is the future. I can
> implement *whole* subsystems in hours that would take weeks with another
> architecture.
>
Good luck with your project then, I'm definitely looking forward to your
first release.
--
Raphael Luta - [EMAIL PROTECTED]
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
