-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rapha�l Luta <[EMAIL PROTECTED]> writes:

> burtonator wrote:
<snip>

> > 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" 

> >>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.

> You may like simple ad-hoc design

It is neither ad-hoc nor simple.

> that fullfill your need but don't limit your creativity. I believe this to be
> a hack and prefer a more engineered approach which provides me with a solid
> manageable and extensible foundation.

Good... then use Reptile.  :)

> > It may not be possible for me to describe the advantages of this new design.
> > Prior to being enlightened to the fact that Emacs was the "one true editor", no
> > one in the world could have convinced me of this fact.  The only way I could
> > learn this was to spend some time hacking on it.
> >
> 
> If you can't explain the advantages of this design, then it's certainly because
> it is definitely not obvious.
> 

I have explained but I don't think you understand.

> >>>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.

> 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.

> >>I think this is a dubious move at best, I'll stick to a manageable programming
> >>language...
> >>
> > You already have one. Java.  With Reptile you can also use Javascript, python,
> > etc.
> > ah... choice is good! :)
> >
> 
> I beg to disagree, sticking to one programming language throughout a project
> is more appealing to me.

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.
 
> >
> >>Also, as you are very well aware, BSF is a Java package which can be used to
> >>include scripting support in any Java application.
> >>
> > Yes but the Xalan integration is much nicer than just raw BSF.
> >
> 
> LOL :)

Why?  I have you read up on the Xalan extensions stuff or played with it?
Really cool!  :)

>  > >>>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.

Everything is then updated and saved without any problem.

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.

> 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.  

> 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>
> 
> Cocoon 2 is one of the best designed piece of software I've seen and I think
> the Cocoon team made a fantastic job in assessing and correcting the issues
> with Cocoon 1 (and they are still doing it).

As do I!

> 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.

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.  

> 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".

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.

- -- 
Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] )
        Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596 

For great justice.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt

iD8DBQE7TXuAAwM6xb2dfE0RAr6LAJ4hHPuHK6XNEWEyYZJI4d40COniBwCglIjb
o1IF1mYkgujbJfsQbs/lKw0=
=iusJ
-----END PGP SIGNATURE-----


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to