You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Gianugo Rabellino <gi...@apache.org> on 2003/11/18 02:58:03 UTC
XSP "official" position
Interesting comments here at ApacheCon. Some users are still convinced
that we're pushing XSP as the prominent way to build interactive stuff
and web applications. Actually on the site there is no particular
endorsement of XSP, but there not either a word of warning about this
approach being "deprecated" in favor of the flow idea. I do think that
it would be nice to put some carefully thought out phrasing on the main
XSP page stating that, while still supported, we do think that there are
now better alternatives for dynamic websites/applications.
WDYT?
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: XSP "official" position
Posted by Vadim Gritsenko <va...@verizon.net>.
Tony Collen wrote:
> Vadim Gritsenko wrote:
>
>> XSP if not perfect, but we still need some kind of "official"
>> templating. What's the alternatives here?
>>
>> ... and it's not that convinient to assemble DOM (or something) in
>> flow and then pass it to the templates... ;-)
>
>
>
> Even the JXTemplateGenerator? I think it's nice and useful.
Sure, it might be nice, and it is useful. Is it cacheable? To give you
simple example:
<xsp:page language="java"
xmlns:xsp="http://apache.org/xsp"
xmlns:xsp-session="http://apache.org/xsp/session/2.0">
<xsp:logic>
public java.io.Serializable getKey()
{
if (request.getSession(false) == null) {
return "0";
} else if(request.getSession().getAttribute("user") != null) {
return "1";
} else {
return "0";
}
}
public SourceValidity getValidity() {
return NOPValidity.SHARED_INSTANCE;
}
</xsp:logic>
<menu>
<page name="Home" link="welcome"/>
...
<xsp:logic>
if(<xsp-session:get-attribute name="user"/> != null) {
<page name="Logout" link="logout"/>
} else {
<page name="Login" link="login"/>
}
</xsp:logic>
</menu>
</xsp:page>
> Perhaps the problem is that the flow layer isn't as "up-front" as
> other things...
What JXTemplateGenerator has to do with flow? AFAIK, it is good without
flow too! :)
Vadim
Re: XSP "official" position
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Tony Collen dijo:
> Vadim Gritsenko wrote:
>
> <snip/>
>
>>
>> XSP if not perfect, but we still need some kind of "official"
>> templating. What's the alternatives here?
>>
>> ... and it's not that convinient to assemble DOM (or something) in flow
>> and then pass it to the templates... ;-)
>
>
> Even the JXTemplateGenerator? I think it's nice and useful. Perhaps
> the problem is that the flow layer isn't as "up-front" as other
> things... that is, you can use Cocoon and never touch the Flow layer.
> People don't realize how useful it is and either shrug it off or try to
> learn it and get angry and go back to XSP.
Yep. But this is also because Flow is too new. The first steps in flow
implementation of are AFAIK by end last year. So it takes long time while
the Cocoon gurus figured out how it would work. I remember strong
discussion about this. And AFAIK Cocoon is the first implementator of this
idea related to XML pipelines.
I am currently using Flow and also I like the idea of use the sitemap with
never writing a line of flow. It is good because some people does not need
flow at all.
Best Regards,
Antonio Gallardo
Re: XSP "official" position
Posted by Leszek Gawron <ou...@wlkp.org>.
On Mon, Nov 17, 2003 at 09:16:23PM -0600, Tony Collen wrote:
> Vadim Gritsenko wrote:
>
> <snip/>
>
> >
> >XSP if not perfect, but we still need some kind of "official"
> >templating. What's the alternatives here?
> >
> >... and it's not that convinient to assemble DOM (or something) in flow
> >and then pass it to the templates... ;-)
>
>
> Even the JXTemplateGenerator? I think it's nice and useful. Perhaps
There is one thing that is really ugly: you do not have jx:attribute command
in jx so you have to repeat the whole tag - and what if that tag contains a
lot of other content?
ouzo
--
__
| / \ | Leszek Gawron // \\
\_\\ //_/ ouzo@wlkp.org _\\()//_
.'/()\'. Phone: +48(501)720812 / // \\ \
\\ // recursive: adj; see recursive | \__/ |
Re: XSP "official" position
Posted by Tony Collen <co...@umn.edu>.
Vadim Gritsenko wrote:
<snip/>
>
> XSP if not perfect, but we still need some kind of "official"
> templating. What's the alternatives here?
>
> ... and it's not that convinient to assemble DOM (or something) in flow
> and then pass it to the templates... ;-)
Even the JXTemplateGenerator? I think it's nice and useful. Perhaps
the problem is that the flow layer isn't as "up-front" as other
things... that is, you can use Cocoon and never touch the Flow layer.
People don't realize how useful it is and either shrug it off or try to
learn it and get angry and go back to XSP.
>
> Vadim
>
>
Regards,
Tony
Re: XSP "official" position
Posted by Vadim Gritsenko <va...@verizon.net>.
Alain Javier Guarnieri del Gesu wrote:
>* Vadim Gritsenko <va...@verizon.net> [2003-11-18 03:03]:
>
>
>>Gianugo Rabellino wrote:
>>
>>
>>
>>>Interesting comments here at ApacheCon. Some users are still convinced
>>>that we're pushing XSP as the prominent way to build interactive stuff
>>>and web applications. Actually on the site there is no particular
>>>endorsement of XSP, but there not either a word of warning about this
>>>approach being "deprecated" in favor of the flow idea. I do think that
>>>it would be nice to put some carefully thought out phrasing on the
>>>main XSP page stating that, while still supported, we do think that
>>>there are now better alternatives for dynamic websites/applications.
>>>
>>>WDYT?
>>>
>>>
>>XSP if not perfect, but we still need some kind of "official"
>>templating. What's the alternatives here?
>>
>>
>
>Is anyone considering XQuery?
>
No. It's slow ( O(xslt) ), for a templating language.
Vadim
Re: XSP "official" position
Posted by Alain Javier Guarnieri del Gesu <ja...@ajgdg.com>.
* Vadim Gritsenko <va...@verizon.net> [2003-11-18 03:03]:
> Gianugo Rabellino wrote:
>
> >Interesting comments here at ApacheCon. Some users are still convinced
> >that we're pushing XSP as the prominent way to build interactive stuff
> >and web applications. Actually on the site there is no particular
> >endorsement of XSP, but there not either a word of warning about this
> >approach being "deprecated" in favor of the flow idea. I do think that
> >it would be nice to put some carefully thought out phrasing on the
> >main XSP page stating that, while still supported, we do think that
> >there are now better alternatives for dynamic websites/applications.
> >
> >WDYT?
>
>
> XSP if not perfect, but we still need some kind of "official"
> templating. What's the alternatives here?
Is anyone considering XQuery?
--
Alain Javier Guarnieri del Gesu - javi@ajgdg.com
Re: XSP "official" position
Posted by Vadim Gritsenko <va...@verizon.net>.
Gianugo Rabellino wrote:
> Interesting comments here at ApacheCon. Some users are still convinced
> that we're pushing XSP as the prominent way to build interactive stuff
> and web applications. Actually on the site there is no particular
> endorsement of XSP, but there not either a word of warning about this
> approach being "deprecated" in favor of the flow idea. I do think that
> it would be nice to put some carefully thought out phrasing on the
> main XSP page stating that, while still supported, we do think that
> there are now better alternatives for dynamic websites/applications.
>
> WDYT?
XSP if not perfect, but we still need some kind of "official"
templating. What's the alternatives here?
... and it's not that convinient to assemble DOM (or something) in flow
and then pass it to the templates... ;-)
Vadim
Re: DB support in flowscript (was: XSP "official" position)
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Leszek Gawron dijo:
> Could you provide me with some link to OJB docs that describe handling
> databases witch triggers modifying the DB content?
http://db.apache.org/ojb/how-to-work-with-stored-procedures.html
(Follow the document, they create some triggers for Oracle in the sample).
Best Regards,
Antonio Gallardo
Re: DB support in flowscript (was: XSP "official" position)
Posted by Leszek Gawron <ou...@wlkp.org>.
On Fri, Nov 21, 2003 at 05:43:00AM -0600, Antonio Gallardo wrote:
> > The second case is :
> > Imagine you have table that describes building (Building) and then you
> > have a
> > table that describes the flat (Flat).
> >
> > Now you want to assign tasks:
> > - visit the flat and do something
> > - visit the whole building (each flat in the building)
> >
> > so you add some more tables:
> > Task
> > TaskBuilding
> > TaskFlat
>
> This can be easily managed using the JDO concept: "extends" inside
> classes. BTW, It is a tipical sample in JDO literature. Changes it to:
> Employees, Managers, Developers, Sellers, etc. You can have a common base
> class "Person". Then you can extend the base class "Person" to another
> "Employee" and from Employee to Managers, Developers, Sellers, etc.
hmmm I do not really see if this is driven by the same metaphor..
> > So now if you want to query for flats that have not been visited it is
> > really
> > simple. But now the database adds/deletes rows from database behind your
> > back.
> > AFAIU this messes up OJB tool completely. Or am I wrong maybe?
>
> :-D Yes, the last is true. OJB can easily manage this and you will not
> have problems. Also you have DB cache and table proxies.
Could you provide me with some link to OJB docs that describe handling
databases witch triggers modifying the DB content?
> Please don't take this mail as an attack. I understand everyone has his
> own programming styles and it is often a trade off. I understand you
> provided them just as samples to illustrate your points.
Exactly, I am still seeking for some convenient way to handle databases. If
yours turns up to be better - let it be - I'm just gonna start using it.
ouzo
--
__
| / \ | Leszek Gawron // \\
\_\\ //_/ ouzo@wlkp.org _\\()//_
.'/()\'. Phone: +48(501)720812 / // \\ \
\\ // recursive: adj; see recursive | \__/ |
Re: DB support in flowscript (was: XSP "official" position)
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Leszek Gawron dijo:
> On Wed, Nov 19, 2003 at 01:36:17PM -0600, Antonio Gallardo wrote:
>> >> > - sometimes the db schema makes it impossible to use O/R tools
>>
>> Show me one. This also denote SQL can be abused. Just for the records,
>> we
>> are currently building an accounting system and O/R works fine there.
>> This
>> is the example you said: a 150+ tables.
> see http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105957045726408&w=2
See also the answer to them:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105958517013233&w=2
I was reviewing old mails and also found the link to the mail you linked
above. At that time, I choosed not answer, because there was already an
answer and it was enough to me. Today, while reviewing old mails, I
started a new answer to them, but choosed again to not reply and closed
the window. It was an old enough mail and tought you already has another
opinion to this. But:
1-Any wrapper around any database is slower than direct native DB access.
This is a fact. Here I can easily include JDBC, ODBC, etc. When we add any
additional instruction for processing, often it is slower.
2-O/R mapping is just an approach to fill the gap between SQL world and OO
world (in this case java).
3-Any of the given models you provided in the linked mail can be easily
converted to O/R mapping. I don't see why not. Note you saw the problem
from the SQL side and not from a OO side. And the view point is very
important to understand the solution. Note in O/R mapping you can choosed
the level of description. If in a given case you don't need a reference
descriptor, you simply don't implement it. That is all.
4-The DB schema 2 and 3 are just design decisions outside the choosed
implementation. Simply, it does not matter if I choose to implement with
XSP, Java, ODBC, JDO, ADO, DAO, ESQL, C++, C, etc.
5-Personally, I will choose the schema 1, because it is cleaner, easily
expandible and has more potential to solve new challenge. Try to explain:
What do you do, if your boss one day said:
"The management decided to add a new question".
How you would manage this in the schema 3? Hehe!
It would simply be a hell. I saw in schema 3 a bunch of "ALTER TABLE" that
innevitable will add 1,000s of empty fields just to make a "dirty patch".
And then? New request how will be solved?
Now the boss comes back again and said that they want to see a report
involving data accross the questionaries! It would be amazing to see the
KB long SQL string we will to send to make 10's of "JOIN"s... of course
the same apply for any O/R tool. This is just a design problem again.
But this RT are just related to design, regardless the implementation you
decide to use. It will be a hell for any of them.
My experience said me:
"Alway let them the path to grow (or "extend it"?). Users never stop
asking new things". (This is again regardless, the implementation).
Also, I believe in DB developers. They have hard time trying to find the
fastest algorithm to improve DB performance. So I will prefer the 2.5M
records + some indexes in ONE table and I am sure it would perform almost
as fast than the proposed schema 3 with +100 tables with less info.
...But note all this decisions are related just to design. No matter O/R
or SQL.
> The second case is :
> Imagine you have table that describes building (Building) and then you
> have a
> table that describes the flat (Flat).
>
> Now you want to assign tasks:
> - visit the flat and do something
> - visit the whole building (each flat in the building)
>
> so you add some more tables:
> Task
> TaskBuilding
> TaskFlat
This can be easily managed using the JDO concept: "extends" inside
classes. BTW, It is a tipical sample in JDO literature. Changes it to:
Employees, Managers, Developers, Sellers, etc. You can have a common base
class "Person". Then you can extend the base class "Person" to another
"Employee" and from Employee to Managers, Developers, Sellers, etc.
It is cleary an OO approach. This is what O/R tools do: allow us think OO.
> You also have to add a TaskBuildingFlatVisited table to be able to report
> which flats have already been visited if a task was for the whole
> building.
>
> Now the problem: you cannot generate a report simply if you do just
> inserts
> into the TaskBuildingFlatVisited table, just because you know which flats
> HAVE
> been visited and it is very hard to query the database for a negated set
> (the
> flats that have not been visited have no corresponding records in the
> database).
> So the solution is simple:
>
> You extend TaskBuildingFlatVisited table with a visited_status column. Now
> you
> create a trigger on TaskBuilding table that for each building task insert
> you
> insert all corresponding flat references to TaskBuildingFlatVisited. Now
> if a
> user visits a flat you do not insert a record - you UPDATE an appropriate
> one.
>
> So now if you want to query for flats that have not been visited it is
> really
> simple. But now the database adds/deletes rows from database behind your
> back.
> AFAIU this messes up OJB tool completely. Or am I wrong maybe?
:-D Yes, the last is true. OJB can easily manage this and you will not
have problems. Also you have DB cache and table proxies.
>> Who said O/R mapping need to be wroten by hand? This is not a MUST
>> anymore. This is mainly why I go to Druid. Did you know Druid? If not
>> here
>> is the link: http://druid.apache.org/ :-D
> This link does not work :)
>
> I've been looking at druid but there is one problem: Druid uses some weird
> technique to detect a JDBC driver in provided jar file. The problem is
> that
> Microsoft SQL Server JDBC driver consists of 3 jar files and even if you
> edit
> the druid configuration by hand it does not detect the driver class.
Hmm... Another "MS game"? I wonder why your DB provider is so smart that
innovated in this area too. :-D ... sorry for the irony. :-(
Seriously, I don't use MS SQL Server. But I hear somewhere the JDBC driver
from MS is slow in OJB. Maybe this is the problem you feel and for this
reasons you are against O/R tools. I hear some people prefer some 3rd
party driver that works faster. Please note I don't use MSSQL, so I cannot
discuss about why and how. It was just a rumor I hear in OJB list: See the
link and the problems related to tables with 5 millions records with MS
SQL. Other people manage this without this type of problems in other
RDBMS. I think the link also show some people working with BIG tables and
O/R tools:
How can they work with so BIG tables with OJB? But they already are. ;-D
http://article.gmane.org/gmane.comp.jakarta.ojb.user/9616/match=+sql+driver+microsoft
>> Using Druid making an O/R mapping is a matter fo secs! Is this a
>> problem?
>> Also + your Beans ready to be used. Well the Beans for JDO are a little
>> bit slower. But I am sure you will have in less than 2 mins you
>> database.jar ready to use. So where is the problem? :-DD
> If you advertise it so strongly I think I will have to try it but first I
> have
> to resolve a problem with the M$ JDBC driver.
I need to warning Druid support for OJB and JDO is just in diapers. Please
don't think it can manage any posible construction. There are some
constructions that it cannot manage, but we are working on.
But I can assure we easily builded 3 diferent databases with +100 tables
each one. So I think Druid can work for the most commons constructions.
Please don't take this mail as an attack. I understand everyone has his
own programming styles and it is often a trade off. I understand you
provided them just as samples to illustrate your points.
O/R tools are not perfect and there is soon a new JDO release 2.0 that
promise to solve some of the currently problems and enhance some weak
areas. But this does not mean you cannot use it right now.
At the end I need to said: "We are betting to O/R mapping". So we had hard
time learning all this new stuff and seems it can work and we will have a
really SoC at the end.
Sorry for this long answer.
Best Regards,
Antonio Gallardo
Re: DB support in flowscript (was: XSP "official" position)
Posted by Leszek Gawron <ou...@wlkp.org>.
On Wed, Nov 19, 2003 at 01:36:17PM -0600, Antonio Gallardo wrote:
> >> > - sometimes the db schema makes it impossible to use O/R tools
>
> Show me one. This also denote SQL can be abused. Just for the records, we
> are currently building an accounting system and O/R works fine there. This
> is the example you said: a 150+ tables.
see http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105957045726408&w=2
The second case is :
Imagine you have table that describes building (Building) and then you have a
table that describes the flat (Flat).
Now you want to assign tasks:
- visit the flat and do something
- visit the whole building (each flat in the building)
so you add some more tables:
Task
TaskBuilding
TaskFlat
You also have to add a TaskBuildingFlatVisited table to be able to report
which flats have already been visited if a task was for the whole building.
Now the problem: you cannot generate a report simply if you do just inserts
into the TaskBuildingFlatVisited table, just because you know which flats HAVE
been visited and it is very hard to query the database for a negated set (the
flats that have not been visited have no corresponding records in the
database).
So the solution is simple:
You extend TaskBuildingFlatVisited table with a visited_status column. Now you
create a trigger on TaskBuilding table that for each building task insert you
insert all corresponding flat references to TaskBuildingFlatVisited. Now if a
user visits a flat you do not insert a record - you UPDATE an appropriate one.
So now if you want to query for flats that have not been visited it is really
simple. But now the database adds/deletes rows from database behind your back.
AFAIU this messes up OJB tool completely. Or am I wrong maybe?
>
> Who said O/R mapping need to be wroten by hand? This is not a MUST
> anymore. This is mainly why I go to Druid. Did you know Druid? If not here
> is the link: http://druid.apache.org/ :-D
This link does not work :)
I've been looking at druid but there is one problem: Druid uses some weird
technique to detect a JDBC driver in provided jar file. The problem is that
Microsoft SQL Server JDBC driver consists of 3 jar files and even if you edit
the druid configuration by hand it does not detect the driver class.
>
> Using Druid making an O/R mapping is a matter fo secs! Is this a problem?
> Also + your Beans ready to be used. Well the Beans for JDO are a little
> bit slower. But I am sure you will have in less than 2 mins you
> database.jar ready to use. So where is the problem? :-DD
If you advertise it so strongly I think I will have to try it but first I have
to resolve a problem with the M$ JDBC driver.
ouzo
--
__
| / \ | Leszek Gawron // \\
\_\\ //_/ ouzo@wlkp.org _\\()//_
.'/()\'. Phone: +48(501)720812 / // \\ \
\\ // recursive: adj; see recursive | \__/ |
Re: DB support in flowscript (was: XSP "official" position)
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Leszek Gawron dijo:
> Continuing the example: cocoon is very powerful in presenting reports. I
> haven't seen a single report tool that does O/R mapping.
Please wait, it is very early to said that. O/R is very new and of course
you are right, but it is just a matter of time.
I don't said O/R tools are the panacea to all our problems, but mixing SQL
+ XSP is ugly even if you take advantage of stored procedures. Believe me
I, we ended a payroll proyect and it was the worst can us happen: SQL+XSP
it is almost unreadable.
> Continuing II: I still cannot picture retrieving 5000 of objects via O/R
> and
> showing them on paginated view - the performance would be tragical.
Depends how you do that. For example OJB support proxies and cache.
>> > - sometimes the db schema makes it impossible to use O/R tools
Show me one. This also denote SQL can be abused. Just for the records, we
are currently building an accounting system and O/R works fine there. This
is the example you said: a 150+ tables.
Who said O/R mapping need to be wroten by hand? This is not a MUST
anymore. This is mainly why I go to Druid. Did you know Druid? If not here
is the link: http://druid.apache.org/ :-D
Using Druid making an O/R mapping is a matter fo secs! Is this a problem?
Also + your Beans ready to be used. Well the Beans for JDO are a little
bit slower. But I am sure you will have in less than 2 mins you
database.jar ready to use. So where is the problem? :-DD
As you see we are doing some improvements. I like to think we are
innovating in this area. An of course the path is not easy. But I think we
will find a Regards at then end.
We are learning, how to work with all this stuff and this allow us to
think new ideas to be implemented. But please wait, we need also to
implement the new ideas too.
Of course you can said us: Hey, wait a minut, there is
XSP+ESQL+ModActions, why use flow+OJB+JDO at all? Well, let us even fail.
If we fail this is a lesson for the community too: The path is wrong.
>> that's possible ...
>>
>> > - in 2 years I haven't found a single project that does not
>> > fall under one
>> > of above conditions
>> >
>> > I would really like to contribute to some flow-db block that
>> > does not involve O/R mapping but do not know where to start from.
>> >
>>
>> Maybe this helps - I like the idea but don't know if this will work ...
>> but I think it worth following it.
>> http://marc.theaimsgroup.com/?t=106761394400006&r=1&w=2
>> (... but it would be OJB based)
>>
>> What I don't want to see in a flow-db block is SQL statements ...
+1
> I think that it should be possible to choose between O/R and pure database
> access. O/R could be a proposed solution and JDBC wrapper a backup one.
> ouzo
Also, please wait. As soon as we will have time you will see your petstore
using OJB too. But just because there is not the OJB petstore this does
not mean it can not exists. It is a matter of time. I repeat.
Best Regards,
Antonio Gallardo
Re: DB support in flowscript (was: XSP "official" position)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 19 Nov 2003, at 12:34, Leszek Gawron wrote:
>
> Continuing II: I still cannot picture retrieving 5000 of objects via
> O/R and
> showing them on paginated view - the performance would be tragical.
>
>
well ... have you tried it?
there was nothing tragic about listing 30000 records from Hibernate
last time I tried ;)
look at :
"Scrollable Iteration" :
http://www.hibernate.org/hib_docs/reference/html/manipulating-
data.html#manipulating-data-s5b
and
"Lazy Initialisation" :
http://www.hibernate.org/hib_docs/reference/html/
collections.html#collections-s1-7
HTH
regards Jeremy
Re: DB support in flowscript
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Tony Collen dijo:
> Ugo Cei wrote:
>> Leszek Gawron wrote:
>>
>>> I'm not advising that also. I am talking about providing an easy
>>> framework for
>>> database operations that would be available from flow.
>>
>
> I had thought about this for a while... a lightweight JDBC wrapper for the
> Flow.
>
> Then I thought about it more... although it might encourage people to
> start writing more things in
> Flowscript, I think the Correct Way(tm) would be to write your business
> logic in a real Java class
> and access it from the Flow that way.
>
> Remember, the Flow is just for controlling the application. I suppose
> then the question is, what
> happens when your logic depends on something in a database?
+1
Best Regards,
Antonio Gallardo
Re: DB support in flowscript
Posted by Tony Collen <co...@umn.edu>.
Ugo Cei wrote:
> Leszek Gawron wrote:
>
>> I'm not advising that also. I am talking about providing an easy
>> framework for
>> database operations that would be available from flow.
>
I had thought about this for a while... a lightweight JDBC wrapper for the Flow.
Then I thought about it more... although it might encourage people to start writing more things in
Flowscript, I think the Correct Way(tm) would be to write your business logic in a real Java class
and access it from the Flow that way.
Remember, the Flow is just for controlling the application. I suppose then the question is, what
happens when your logic depends on something in a database?
> Which kind of framework? What patterns would it implement? If you take a
> look at Martin Fowler's catalog of Enterprise Application Patterns [1],
> you'll see quite a few having to do with accessing data sources.
>
> What I'm trying to say is that there is no "right way" to implement
> this, so I'm -0.5 against providing any kind of JDBC encapsulation code
> in flowscript, like it were some kind of "best practice".
I would have to agree with this. It's tempting to make the Flow "as easy as PHP" and just give
everybody tons of functions to do stuff with. The problem is if we provide too much, then people
will just start writing EVERYTHING in the Flow, and before you know it, it's out of hand.
I guess the same would go for the use case of wanting to fire off a simple email message from the
Flow. But I guess if the user wants to do something that complicated, it would be trivial for them
to just write a helper class in Java that they could access through Packages.*
Thoughts?
Tony
Re: DB support in flowscript
Posted by Ugo Cei <u....@cbim.it>.
Leszek Gawron wrote:
> I'm not advising that also. I am talking about providing an easy framework for
> database operations that would be available from flow.
Which kind of framework? What patterns would it implement? If you take a
look at Martin Fowler's catalog of Enterprise Application Patterns [1],
you'll see quite a few having to do with accessing data sources.
What I'm trying to say is that there is no "right way" to implement
this, so I'm -0.5 against providing any kind of JDBC encapsulation code
in flowscript, like it were some kind of "best practice".
Ugo
[1] http://www.martinfowler.com/eaaCatalog/
Re: DB support in flowscript (was: XSP "official" position)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 19 Nov 2003, at 19:03, Tony Collen wrote:
> Yep, this is the easy way. I could see this being the answer to some
> FAQ:
>
> Q: How can I easily send an email from the Flow layer?
>
> A: The simple way is to write an XSP, and call the XSP's pipeline from
> within the Flowscript. If you need something a little cleaner, you
> can simply write a helper class in Java and access it from your Flow
> as an object.
>
or:
The Flowscript:
importPackage (Packages.org.apache.cocoon.mail);
function sendMail (smtpHost, bodysrc, to, from, subject, bean) {
var mailer = new MailMessageSender (smtpHost);
mailer.setFrom (from);
mailer.setTo (to);
mailer.setSubject (subject);
// use a JXTemplate to produce the body from the 'bean'
var output = new Packages.java.io.ByteArrayOutputStream ();
cocoon.processPipelineTo (bodysrc, { bean: bean }, output);
mailer.setBody (output.toString ());
mailer.send (null); // a null resolver, because we do not need one
}
NB. MailMessageSender can take a 'src' of a pipeline to call to get the
email body, but it does not take a bean as a parameter. So I can do it
like the above.
The template:
<document xmlns:t="http://apache.org/cocoon/templates/jx/1.0">
To: #{bean/firstname} #{bean/lastname}.
You have been successfully registered with our site.
http://the.url.here
Your login is: #{bean/email}
We hope you remember your password!
</document>
The Pipeline:
<map:match pattern="mail/*">
<map:generate type="jx" src="content/mail/{1}.xml"/>
<map:serialize type="text"/>
</map:match>
HTH
regards Jeremy
Re: DB support in flowscript (was: XSP "official" position)
Posted by Tony Collen <co...@umn.edu>.
Ugo Cei wrote:
>
> P.S.: by the way, is it possible to restart a context with Jetty like it
> is with Tomcat, and how?
>
I've found:
http://groups.yahoo.com/group/jetty-support/message/1622
http://jetty.mortbay.org/jetty/doc/reloadServlets.html
Tony
Re: DB support in flowscript (was: XSP "official" position)
Posted by Upayavira <uv...@upaya.co.uk>.
Tony Collen wrote:
> Upayavira wrote:
>
>> I have logged into another PC with PCAnywhere and tried
>> http://charya:8889. (My PC is charya). It didn't work. I removed the
>> Host line, and restarted, and it did.
>>
>> I guess that is reasonably conclusive, isn't it? ;-)
>
>
> Mmmh. Not neccessarily. If the default is to bind to your NIC's
> public IP (i.e. with no host line), then you'd be able to access Jetty
> from any computer that can reach that public IP address.
>
> As a test I set the host to my public IP address, and I get the
> following message when I start Jetty:
>
> 17:55:04.016 EVENT Started SocketListener on 0.0.0.0:8888
> 17:55:04.016 EVENT Started org.mortbay.jetty.Server@291aff
> 17:55:04.086 EVENT Starting Jetty/4.2.9
> 17:55:04.096 EVENT Started ServletHttpContext[/]
> 17:55:04.106 EVENT Started SocketListener on [MY_PUBLIC_IP_ADDRESS]:8889
> 17:55:04.106 EVENT Started org.mortbay.jetty.Server@107f45d
>
>
> And I was able to access the admin servlet from over the Internet.
> Likewise, when i set it to 127.0.0.1:
>
> 17:56:17.511 EVENT Started SocketListener on 127.0.0.1:8889
>
> And I can only reach the machine from "localhost" (aka 127.0.0.1)
>
> It's the IP address it binds to, I tell you! :)
Ah. Gocha. It is the interface on which it listens. And if it listens on
loopback (127.0.0.1), it'll only hear requests from localhost. If you
skip the Host parameter, it'll listen on all interfaces.
Makes sense.
Regards, Upayavira
Re: DB support in flowscript (was: XSP "official" position)
Posted by Tony Collen <co...@umn.edu>.
Upayavira wrote:
> I have logged into another PC with PCAnywhere and tried
> http://charya:8889. (My PC is charya). It didn't work. I removed the
> Host line, and restarted, and it did.
>
> I guess that is reasonably conclusive, isn't it? ;-)
Mmmh. Not neccessarily. If the default is to bind to your NIC's public IP (i.e. with no host
line), then you'd be able to access Jetty from any computer that can reach that public IP address.
As a test I set the host to my public IP address, and I get the following message when I start Jetty:
17:55:04.016 EVENT Started SocketListener on 0.0.0.0:8888
17:55:04.016 EVENT Started org.mortbay.jetty.Server@291aff
17:55:04.086 EVENT Starting Jetty/4.2.9
17:55:04.096 EVENT Started ServletHttpContext[/]
17:55:04.106 EVENT Started SocketListener on [MY_PUBLIC_IP_ADDRESS]:8889
17:55:04.106 EVENT Started org.mortbay.jetty.Server@107f45d
And I was able to access the admin servlet from over the Internet. Likewise, when i set it to
127.0.0.1:
17:56:17.511 EVENT Started SocketListener on 127.0.0.1:8889
And I can only reach the machine from "localhost" (aka 127.0.0.1)
It's the IP address it binds to, I tell you! :)
Tony
Re: DB support in flowscript (was: XSP "official" position)
Posted by Upayavira <uv...@upaya.co.uk>.
Tony Collen wrote:
> Upayavira wrote:
>
>> Note the <Set name="Host">127.0.0.1</Set> line. This sets the host
>> that it will accept connections from. I reckon if you remove this
>> line, it'll accept connections from elsewhere too.
>
>
> I'm no Jetty expert, but wouldn't that be the IP address that it binds
> to, not the IP address to accept connections fom?
Look in the main.xml file, it makes no mention of Host.
I have logged into another PC with PCAnywhere and tried
http://charya:8889. (My PC is charya). It didn't work. I removed the
Host line, and restarted, and it did.
I guess that is reasonably conclusive, isn't it? ;-)
Regards, Upayavira
Re: DB support in flowscript (was: XSP "official" position)
Posted by Tony Collen <co...@umn.edu>.
Upayavira wrote:
> Note the <Set name="Host">127.0.0.1</Set> line. This sets the host that
> it will accept connections from. I reckon if you remove this line, it'll
> accept connections from elsewhere too.
I'm no Jetty expert, but wouldn't that be the IP address that it binds to, not the IP address to
accept connections fom?
>
> Regards, Upayavira
>
Tony
Re: DB support in flowscript (was: XSP "official" position)
Posted by Upayavira <uv...@upaya.co.uk>.
Ugo Cei wrote:
> Upayavira wrote:
>
>> Still a hassle to switch to another window, shut it down, wait.....,
>> restart, then connect your debugger to the waiting instance, then
>> request a page from Cocoon and wait...:-(
>
>
> Then you don't have a fast enough machine ;-),
700MHz, 512Mb (and full). One day. But I am impressed how long it has
lasted (nearly three years).
> And if you wrote more tests, you wouldn't need a debugger so often.
Yup. Will get there. I'm sure once I've started, I'll just keep doing it.
>> It seems you can do a standard http request to, for example
>> http://localhost:8889/?A=Start&ID=1:null:/:0
>
> Ah OK, actually I knew about that, but I tend to forget. Another
> question, if you don't mind, isn't it possible to use Jetty's admin
> interface from a host different from localhost?
Look in tools/jetty/conf/admin.xml. In there you'll see:
<Call name="addListener">
<Arg>
<New class="org.mortbay.http.SocketListener">
<Set name="Host">127.0.0.1</Set>
<Set name="Port"><SystemProperty name="jetty.admin.port"
default="8081"/></Set>
<Set name="MinThreads">5</Set>
<Set name="MaxThreads">100</Set>
<Set name="MaxIdleTimeMs">30000</Set>
<Set name="LowResourcePersistTimeMs">5000</Set>
</New>
</Arg>
</Call>
Note the <Set name="Host">127.0.0.1</Set> line. This sets the host that
it will accept connections from. I reckon if you remove this line, it'll
accept connections from elsewhere too.
Regards, Upayavira
Re: DB support in flowscript (was: XSP "official" position)
Posted by Ugo Cei <u....@cbim.it>.
Upayavira wrote:
> Still a hassle to switch to another window, shut it down, wait.....,
> restart, then connect your debugger to the waiting instance, then
> request a page from Cocoon and wait...:-(
Then you don't have a fast enough machine ;-), And if you wrote more
tests, you wouldn't need a debugger so often.
> It seems you can do a standard http request to, for example
> http://localhost:8889/?A=Start&ID=1:null:/:0
Ah OK, actually I knew about that, but I tend to forget. Another
question, if you don't mind, isn't it possible to use Jetty's admin
interface from a host different from localhost?
Ugo
Re: DB support in flowscript (was: XSP "official" position)
Posted by Upayavira <uv...@upaya.co.uk>.
Ugo Cei wrote:
> Upayavira wrote:
>
>> 1) The most complicated bit I have found in building Cocoon sites is
>> handling Java classes. If deployed in a jar, it always seems to
>> require a server/app restart to take on the changes. For trivial
>> things (e.g. sending a simple email), I wouldn't want to have to get
>> all this Java stuff going.
>
> Then you should:
>
> A) test your classes in isolation _before_ debugging them in Cocoon
Yup. Will get into doing that some day soon.
> B) get yourself a fast machine and with the "cocoon servlet" task,
> restarting the container is a breeze, especially if you tune your
> Cocoon to have only the minimum set of blocks needed.
Still a hassle to switch to another window, shut it down, wait.....,
restart, then connect your debugger to the waiting instance, then
request a page from Cocoon and wait...:-(
I'll get there.
> But then again, YMMV ;-)
>
> Ugo
>
> P.S.: by the way, is it possible to restart a context with Jetty like
> it is with Tomcat, and how?
Do cocoon servlet-admin
and go to http://localhost:8889/
It seems you can do a standard http request to, for example
http://localhost:8889/?A=Start&ID=1:null:/:0
(note, I removed the T parameter, which changes every time, and it still
seemed to work).
I believe you could put this HTTP request into an Ant script using the
<get> task.
I wonder if there might be a need for a cocoon servlet-debug-admin that
allows both debugging and admin (e.g. to allow you to automatically
restart your jetty for debugging).
Regards, Upayavira
Re: DB support in flowscript (was: XSP "official" position)
Posted by Ugo Cei <u....@cbim.it>.
Upayavira wrote:
> 1) The most complicated bit I have found in building Cocoon sites is
> handling Java classes. If deployed in a jar, it always seems to require
> a server/app restart to take on the changes. For trivial things (e.g.
> sending a simple email), I wouldn't want to have to get all this Java
> stuff going.
Then you should:
A) test your classes in isolation _before_ debugging them in Cocoon
B) get yourself a fast machine and with the "cocoon servlet" task,
restarting the container is a breeze, especially if you tune your Cocoon
to have only the minimum set of blocks needed.
But then again, YMMV ;-)
Ugo
P.S.: by the way, is it possible to restart a context with Jetty like it
is with Tomcat, and how?
Re: DB support in flowscript (was: XSP "official" position)
Posted by Tony Collen <co...@umn.edu>.
Upayavira wrote:
> 1) The most complicated bit I have found in building Cocoon sites is
> handling Java classes. If deployed in a jar, it always seems to require
> a server/app restart to take on the changes. For trivial things (e.g.
> sending a simple email), I wouldn't want to have to get all this Java
> stuff going.
I agree, this is sort of a pain in the butt.
> 2) Some Cocoon users aren't Java developers. They may extend to
> Javascript, but Java will be beyond them. If simple utility classes can
> be provided that allow such things as sending emails from flow, I don't
> see the problem.
Agreed. IMO though you will get to a level of complexity in your application where you WILL have to
code. Maybe it is worth investigating writing some utility scripts for little things like this.
> 3) I can see the problem with database code in flow. Databases are
> inherently complicated and incredibly varied. There's a lot less options
> with sending an email though.
>
Again, I agree. Think about what happens when you have some Flow that accesses an object, which
commits some sort of JDO transaction. If you call a previous continuation, you obviously need to
rollBack(). Looks a little hairy to me.
> Regards, Upayavira
>
Tony
RE: DB support in flowscript (was: XSP "official" position)
Posted by Reinhard Poetz <re...@apache.org>.
From: Upayavira
> Tony Collen wrote:
> ...
>
> > Yep, this is the easy way. I could see this being the
> answer to some
> > FAQ:
> >
> > Q: How can I easily send an email from the Flow layer?
> >
> > A: The simple way is to write an XSP, and call the XSP's
> pipeline from
> > within the Flowscript. If you need something a little cleaner, you
> > can simply write a helper class in Java and access it from
> your Flow
> > as an object.
>
> 1) The most complicated bit I have found in building Cocoon sites is
> handling Java classes. If deployed in a jar, it always seems
> to require
> a server/app restart to take on the changes. For trivial things (e.g.
> sending a simple email), I wouldn't want to have to get all this Java
> stuff going.
you can use hot deployment (at least tomcat supports it)
> 2) Some Cocoon users aren't Java developers. They may extend to
> Javascript, but Java will be beyond them.
Maybe the question is: Is it possible to write 'transaction-centric'
applications without knowing Java within Cocoon? I'm not sure about
this.
Maybe Sylvain's idea using dynamic beans could help here ...
> If simple utility
> classes can
> be provided that allow such things as sending emails from
> flow, I don't
> see the problem.
utiliy classes or pipelines ... +1 for both
> 3) I can see the problem with database code in flow. Databases are
> inherently complicated and incredibly varied. There's a lot
> less options
> with sending an email though.
yep
--
Reinhard
Re: DB support in flowscript (was: XSP "official" position)
Posted by Upayavira <uv...@upaya.co.uk>.
Tony Collen wrote:
...
> Yep, this is the easy way. I could see this being the answer to some
> FAQ:
>
> Q: How can I easily send an email from the Flow layer?
>
> A: The simple way is to write an XSP, and call the XSP's pipeline from
> within the Flowscript. If you need something a little cleaner, you
> can simply write a helper class in Java and access it from your Flow
> as an object.
1) The most complicated bit I have found in building Cocoon sites is
handling Java classes. If deployed in a jar, it always seems to require
a server/app restart to take on the changes. For trivial things (e.g.
sending a simple email), I wouldn't want to have to get all this Java
stuff going.
2) Some Cocoon users aren't Java developers. They may extend to
Javascript, but Java will be beyond them. If simple utility classes can
be provided that allow such things as sending emails from flow, I don't
see the problem.
3) I can see the problem with database code in flow. Databases are
inherently complicated and incredibly varied. There's a lot less options
with sending an email though.
Regards, Upayavira
Re: DB support in flowscript (was: XSP "official" position)
Posted by Tony Collen <co...@umn.edu>.
Reinhard Poetz wrote:
> If you have to implement transaction logic I think there is no way
> around Flowscript/CocoonForms/DataObjects(via O/R-mapping or EJB) in
> order to reach a clean design.
>
> I think this is the message for our users.
+100000. Time to start spreading the gospel :)
IMO strong Flow + Forms + OJB / JDO / O/R will get Cocoon widespread acceptance. That, and good
documentation :)
> One further thought on DB and flowscript:
> If you want to combine the ease of use of XSP and flowscript and you
> don't want to mix concerns - why don't you call pipelines from within
> your flowscript?
Yep, this is the easy way. I could see this being the answer to some FAQ:
Q: How can I easily send an email from the Flow layer?
A: The simple way is to write an XSP, and call the XSP's pipeline from within the Flowscript. If
you need something a little cleaner, you can simply write a helper class in Java and access it from
your Flow as an object.
> Then you can do all the things XSP/ESQL offer having direct database
> access. And I don't know how it should become easier if we build a
> specif 'flow-database-framework' compared to the flexibility of Cocoon
> pipelines which are called from within the flow layer. This also means
> that you have caching (--> pipeline caching) for free.
Regards,
Tony
RE: DB support in flowscript (was: XSP "official" position)
Posted by Reinhard Poetz <re...@apache.org>.
From: Leszek Gawron
> On Wed, Nov 19, 2003 at 12:01:41PM +0100, Reinhard Poetz wrote:
> >
> > From: Leszek Gawron
> >
> > > On Mon, Nov 17, 2003 at 09:01:57PM -0600, Antonio Gallardo wrote:
> > > > I really no wonder why peope still think XSP is the great
> > > Gig in the
> > > > Cocoon town, because if you google around you will feel this is
> > > > the way Cocoon goes. To be honest I don't google about
> this for a
> > > > long time but still early this year this was the tendency.
> > > xsp is very powerful if you use it with esql.
> > >
> > > - very fast custom database action creation (xsp actions)
> > > - nice syntax, no need for enormous amount of JDBC code
> needed, no
> > > need to
> > > handle exceptions
> > > - esql is customized transparently for several databases (
> > > i.e. max-rows,
> > > skip-rows) - very useful for me because I connect
> cocoon to existing
> > > database installations so I do not have the comfort to
> > > choose one that fits
> > > the best.
> > >
> > > while the flow:
> > > - has some database support but is really poor
> >
> > I wouldn't code my DB support in Javascript
> I'm not advising that also. I am talking about providing an
> easy framework for database operations that would be
> available from flow.
>
>
> and really: why not ? I usually make two scripts :
> controller.js and persistence.js. JS has a great feature: it
> is interpreted so all you need is a text editor. You just
> apply changes and everything works without
> - building new classes
> - jar packaging
> - stopping the container
> - replacing the jar
> - starting the container
>
> >
> > > - you have to catch exceptions yourself
> >
> > who else should catch them for you?
> SQLExceptions should be beclared or thrown. Simple JDBC
> wrappers usually convert almost all of them to
> RuntimeExceptions. 90% of exceptions usually denote a design
> time or fatal error so there is really no point to recover from them
> - it just should be simply logged
>
> >
> > > - no database customizations
> >
> > I think flowscript shouldn't support DB access directly
> Maybe you're right but if you drop XSP what database support
> you have?
> Actions? Then can be used for really simple processing as
> using them for more advanced features makes it harder than
> using pure JDBC.
>
> Please note also that the biggest cocoon application example
> - Petstore - accesses database directly from JS.
>
> >
> > > - O/R support is still pre-alpha and even if it was already mature
> > > - the overhead is much too big comparing to pure JDBC
> for projects
> > > not-enterprise size
> >
> > This is valid for your first project but it's like with
> Cocoon: After
> > your first Cocoon project many of us also take it as
> platform for very
> > simple projects. The last few weeks I learned more and more
> about OJB
> > and you can be sure I'll take it in many projects in the
> future - also
> > in projects where I wouldn't have taken it in the past because I
> > *thought* it is too complicated (in opposite - using OJB
> makes it much
> > easier!)
> >
> > > - you cannot use it for web applications that use already ready
> > > database
> > > schema - try to add some functionality to big accounting
> > > system - you
> > > would have to map almost whole existing db even if you
> > > need access to 3-4
> > > tables
> >
> > I think if you can remove all those SQL-statements out of your code
> > which is IMO very ugly it's worth doing it.
>
> That's not the point - if you have an accounting system there
> are usually about 150 tables (very large). If you implement a
> simple plugin to that system you usually are concerned about
> a few of them while the OJB would need to map ALL refences
> between database tables.
>
> Continuing the example: cocoon is very powerful in presenting
> reports. I haven't seen a single report tool that does O/R mapping.
>
> Continuing II: I still cannot picture retrieving 5000 of
> objects via O/R and showing them on paginated view - the
> performance would be tragical.
>
> >
> > > - sometimes the db schema makes it impossible to use O/R tools
> >
> > that's possible ...
> >
> > > - in 2 years I haven't found a single project that does not
> > > fall under one
> > > of above conditions
> > >
> > > I would really like to contribute to some flow-db block that does
> > > not involve O/R mapping but do not know where to start from.
> > >
> >
> > Maybe this helps - I like the idea but don't know if this will work
> > ... but I think it worth following it.
> > http://marc.theaimsgroup.com/?t=106761394400006&r=1&w=2
> > (... but it would be OJB based)
> >
> > What I don't want to see in a flow-db block is SQL statements ...
> I think that it should be possible to choose between O/R and
> pure database access. O/R could be a proposed solution and
> JDBC wrapper a backup one.
I separate between applications which are more 'publishing-centric' and
which are more 'transaction-centric'. 'publishing-centric'-applications
usually don't need flowscript. Your example (reporting tools) is of
course a representative of the this type and XSP(using ESQL) or
SQL-Transformer is the easierst way.
If you have to implement transaction logic I think there is no way
around Flowscript/CocoonForms/DataObjects(via O/R-mapping or EJB) in
order to reach a clean design.
I think this is the message for our users.
One further thought on DB and flowscript:
If you want to combine the ease of use of XSP and flowscript and you
don't want to mix concerns - why don't you call pipelines from within
your flowscript?
Then you can do all the things XSP/ESQL offer having direct database
access. And I don't know how it should become easier if we build a
specif 'flow-database-framework' compared to the flexibility of Cocoon
pipelines which are called from within the flow layer. This also means
that you have caching (--> pipeline caching) for free.
--
Reinhard
Re: DB support in flowscript (was: XSP "official" position)
Posted by Leszek Gawron <ou...@wlkp.org>.
On Wed, Nov 19, 2003 at 12:01:41PM +0100, Reinhard Poetz wrote:
>
> From: Leszek Gawron
>
> > On Mon, Nov 17, 2003 at 09:01:57PM -0600, Antonio Gallardo wrote:
> > > I really no wonder why peope still think XSP is the great
> > Gig in the
> > > Cocoon town, because if you google around you will feel this is the
> > > way Cocoon goes. To be honest I don't google about this for a long
> > > time but still early this year this was the tendency.
> > xsp is very powerful if you use it with esql.
> >
> > - very fast custom database action creation (xsp actions)
> > - nice syntax, no need for enormous amount of JDBC code
> > needed, no need to
> > handle exceptions
> > - esql is customized transparently for several databases (
> > i.e. max-rows,
> > skip-rows) - very useful for me because I connect cocoon to existing
> > database installations so I do not have the comfort to
> > choose one that fits
> > the best.
> >
> > while the flow:
> > - has some database support but is really poor
>
> I wouldn't code my DB support in Javascript
I'm not advising that also. I am talking about providing an easy framework for
database operations that would be available from flow.
and really: why not ? I usually make two scripts : controller.js and
persistence.js. JS has a great feature: it is interpreted so all you need is a
text editor. You just apply changes and everything works without
- building new classes
- jar packaging
- stopping the container
- replacing the jar
- starting the container
>
> > - you have to catch exceptions yourself
>
> who else should catch them for you?
SQLExceptions should be beclared or thrown. Simple JDBC wrappers usually
convert almost all of them to RuntimeExceptions. 90% of exceptions usually denote
a design time or fatal error so there is really no point to recover from them
- it just should be simply logged
>
> > - no database customizations
>
> I think flowscript shouldn't support DB access directly
Maybe you're right but if you drop XSP what database support you have?
Actions? Then can be used for really simple processing as using them for more
advanced features makes it harder than using pure JDBC.
Please note also that the biggest cocoon application example - Petstore -
accesses database directly from JS.
>
> > - O/R support is still pre-alpha and even if it was already mature
> > - the overhead is much too big comparing to pure JDBC for projects
> > not-enterprise size
>
> This is valid for your first project but it's like with Cocoon: After
> your first Cocoon project many of us also take it as platform for very
> simple projects.
> The last few weeks I learned more and more about OJB and you can be sure
> I'll take it in many projects in the future - also in projects where I
> wouldn't have taken it in the past because I *thought* it is too
> complicated (in opposite - using OJB makes it much easier!)
>
> > - you cannot use it for web applications that use already
> > ready database
> > schema - try to add some functionality to big accounting
> > system - you
> > would have to map almost whole existing db even if you
> > need access to 3-4
> > tables
>
> I think if you can remove all those SQL-statements out of your code
> which is IMO very ugly it's worth doing it.
That's not the point - if you have an accounting system there are usually
about 150 tables (very large). If you implement a simple plugin to that system
you usually are concerned about a few of them while the OJB would need to map
ALL refences between database tables.
Continuing the example: cocoon is very powerful in presenting reports. I
haven't seen a single report tool that does O/R mapping.
Continuing II: I still cannot picture retrieving 5000 of objects via O/R and
showing them on paginated view - the performance would be tragical.
>
> > - sometimes the db schema makes it impossible to use O/R tools
>
> that's possible ...
>
> > - in 2 years I haven't found a single project that does not
> > fall under one
> > of above conditions
> >
> > I would really like to contribute to some flow-db block that
> > does not involve O/R mapping but do not know where to start from.
> >
>
> Maybe this helps - I like the idea but don't know if this will work ...
> but I think it worth following it.
> http://marc.theaimsgroup.com/?t=106761394400006&r=1&w=2
> (... but it would be OJB based)
>
> What I don't want to see in a flow-db block is SQL statements ...
I think that it should be possible to choose between O/R and pure database
access. O/R could be a proposed solution and JDBC wrapper a backup one.
ouzo
--
__
| / \ | Leszek Gawron // \\
\_\\ //_/ ouzo@wlkp.org _\\()//_
.'/()\'. Phone: +48(501)720812 / // \\ \
\\ // recursive: adj; see recursive | \__/ |
Re: XSP "official" position
Posted by Steve K <sh...@mm.st>.
I've never liked the idea of putting controller logic in XSP pages,
however, new users of Cocoon that come from server-page backgrounds will
probably want to do this because that is what they're used to. I think
this is a really bad thing because if you approach things this way, you
really miss what Cocoon is all about.
I don't think I'd go as far as saying XSP is deprecated, but it may be
useful to reposition it (possibly rename it?) as an easy way to create
custom generators. I think that would cause people to think of using it
more for view-related tasks.
And while it is true that a template system like JXTemplate can do a lot
of what XSP does when dealing with the view, there remains a lot of
utility when using xsp and existing logicsheets. On my current project,
I've found that I had better control of my XML output when using xsp +
esql logicsheet over the SQLTransformer (however, nothing I don't
believe couldn't be righted with another transform). Also, sending
email whose content is generated by a pipeline seems much easier to do
with xsp + sendmail logicsheet than in an action or flow.
cheers,
-steve
Re: XSP "official" position
Posted by Sylvain Wallez <sy...@apache.org>.
Leszek Gawron wrote:
<snip/>
>Jakarta commons has something called DBUtils
>(http://jakarta.apache.org/commons/dbutils/index.html) - I do not know the
>functionality but I suppose if this was wrapped with Scriptable I think it
>would be very useful.
>
>
Mmmmh... Populating a JS object directly from a ResultSet definitely
looks interesting!!!
Too bad it doesn't support updading/inserting an object into the
database :-(
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
DB support in flowscript (was: XSP "official" position)
Posted by Reinhard Poetz <re...@apache.org>.
From: Leszek Gawron
> On Mon, Nov 17, 2003 at 09:01:57PM -0600, Antonio Gallardo wrote:
> > I really no wonder why peope still think XSP is the great
> Gig in the
> > Cocoon town, because if you google around you will feel this is the
> > way Cocoon goes. To be honest I don't google about this for a long
> > time but still early this year this was the tendency.
> xsp is very powerful if you use it with esql.
>
> - very fast custom database action creation (xsp actions)
> - nice syntax, no need for enormous amount of JDBC code
> needed, no need to
> handle exceptions
> - esql is customized transparently for several databases (
> i.e. max-rows,
> skip-rows) - very useful for me because I connect cocoon to existing
> database installations so I do not have the comfort to
> choose one that fits
> the best.
>
> while the flow:
> - has some database support but is really poor
I wouldn't code my DB support in Javascript
> - you have to catch exceptions yourself
who else should catch them for you?
> - no database customizations
I think flowscript shouldn't support DB access directly
> - O/R support is still pre-alpha and even if it was already mature
> - the overhead is much too big comparing to pure JDBC for projects
> not-enterprise size
This is valid for your first project but it's like with Cocoon: After
your first Cocoon project many of us also take it as platform for very
simple projects.
The last few weeks I learned more and more about OJB and you can be sure
I'll take it in many projects in the future - also in projects where I
wouldn't have taken it in the past because I *thought* it is too
complicated (in opposite - using OJB makes it much easier!)
> - you cannot use it for web applications that use already
> ready database
> schema - try to add some functionality to big accounting
> system - you
> would have to map almost whole existing db even if you
> need access to 3-4
> tables
I think if you can remove all those SQL-statements out of your code
which is IMO very ugly it's worth doing it.
> - sometimes the db schema makes it impossible to use O/R tools
that's possible ...
> - in 2 years I haven't found a single project that does not
> fall under one
> of above conditions
>
> I would really like to contribute to some flow-db block that
> does not involve O/R mapping but do not know where to start from.
>
Maybe this helps - I like the idea but don't know if this will work ...
but I think it worth following it.
http://marc.theaimsgroup.com/?t=106761394400006&r=1&w=2
(... but it would be OJB based)
What I don't want to see in a flow-db block is SQL statements ...
--
Reinhard
Re: XSP "official" position
Posted by Leszek Gawron <ou...@wlkp.org>.
On Mon, Nov 17, 2003 at 09:01:57PM -0600, Antonio Gallardo wrote:
> I really no wonder why peope still think XSP is the great Gig in the
> Cocoon town, because if you google around you will feel this is the way
> Cocoon goes. To be honest I don't google about this for a long time but
> still early this year this was the tendency.
xsp is very powerful if you use it with esql.
- very fast custom database action creation (xsp actions)
- nice syntax, no need for enormous amount of JDBC code needed, no need to
handle exceptions
- esql is customized transparently for several databases ( i.e. max-rows,
skip-rows) - very useful for me because I connect cocoon to existing
database installations so I do not have the comfort to choose one that fits
the best.
while the flow:
- has some database support but is really poor
- you have to catch exceptions yourself
- no database customizations
- O/R support is still pre-alpha and even if it was already mature
- the overhead is much too big comparing to pure JDBC for projects
not-enterprise size
- you cannot use it for web applications that use already ready database
schema - try to add some functionality to big accounting system - you
would have to map almost whole existing db even if you need access to 3-4
tables
- sometimes the db schema makes it impossible to use O/R tools
- in 2 years I haven't found a single project that does not fall under one
of above conditions
I would really like to contribute to some flow-db block that does not involve
O/R mapping but do not know where to start from.
Jakarta commons has something called DBUtils
(http://jakarta.apache.org/commons/dbutils/index.html) - I do not know the
functionality but I suppose if this was wrapped with Scriptable I think it
would be very useful.
ouzo
--
__
| / \ | Leszek Gawron // \\
\_\\ //_/ ouzo@wlkp.org _\\()//_
.'/()\'. Phone: +48(501)720812 / // \\ \
\\ // recursive: adj; see recursive | \__/ |
Re: XSP "official" position
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Gianugo Rabellino dijo:
> Interesting comments here at ApacheCon. Some users are still convinced
> that we're pushing XSP as the prominent way to build interactive stuff
> and web applications.
Incredible enough! 8-0
BTW, tell then they are totally outdated. :-D
> Actually on the site there is no particular
> endorsement of XSP, but there not either a word of warning about this
> approach being "deprecated" in favor of the flow idea.
Here I will and transformers too.
> I do think that
> it would be nice to put some carefully thought out phrasing on the main
> XSP page stating that, while still supported, we do think that there are
> now better alternatives for dynamic websites/applications.
Yep. +1
>
> WDYT?
I had concerns and tought about this for long time:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103543889904222&w=2
As an "old" XSP user I think XSP is good for some rapid prototyping and
for some small sites (Matthew and Carten book stated about it clearly).
The problems using XSP in webapp I painfull learned while working with it.
:-(
I think we will continue supporting XSP because Cocoon can be used as Web
publishing framework or a Webapp framework. Also XSP is a good entry point
for many people from the ASP, PHP world. They feels like fish in the water
with XSP. :-D
I really no wonder why peope still think XSP is the great Gig in the
Cocoon town, because if you google around you will feel this is the way
Cocoon goes. To be honest I don't google about this for a long time but
still early this year this was the tendency.
OK. I google again :-D here the results:
Search for: "Apache Cocoon" results: 447,000 (we are slowing growing!)
Search for: "Cocoon XSP" results: 61,700
Search for: "Cocoon XSLT" results: 48,300
Search for: "Cocoon Flow" results: 42,100
Search for: "Cocoon Transformer" results: 15,800
Best Regards,
Antonio Gallardo
ExcaliburTestCase broken in 2.1.3
Posted by Steve K <sh...@mm.st>.
Hey folks --
It looks like the ExcaliburTestCase is broken in 2.1.3. If you run
./build.sh test, the junit tests that extend ExcaliburTestCase run but
none of the tests get executed:
Running org.apache.cocoon.generation.FileGeneratorTestCase
Tests run: 0, Failures: 0, Errors: 0, Time elapsed: 0.001 sec
Testsuite: org.apache.cocoon.generation.FileGeneratorTestCase
Tests run: 0, Failures: 0, Errors: 0, Time elapsed: 0.001 sec
Running org.apache.cocoon.transformation.TraxTransformerTestCase
Tests run: 0, Failures: 0, Errors: 0, Time elapsed: 0.001 sec
Testsuite: org.apache.cocoon.transformation.TraxTransformerTestCase
Tests run: 0, Failures: 0, Errors: 0, Time elapsed: 0.001 sec
Running org.apache.cocoon.acting.RequestParamActionTestCase
Tests run: 0, Failures: 0, Errors: 0, Time elapsed: 0 sec
Testsuite: org.apache.cocoon.acting.RequestParamActionTestCase
Tests run: 0, Failures: 0, Errors: 0, Time elapsed: 0 sec
Note the "Test run: 0" on each line. It looks like something went wrong
with the class with the recent maven-ification of the avalon-excalibur
repository. For some reason, the current version in the repository will
enumerate the methods on the ExcaliburTestCase class to find the test
methods, rather than enumerating the methods on this.getClass() -- the
subclass that actually has the tests in it.
What appears to be the older, working version of the ExcaliburTestCase
class can be found in the avalon-sandbox repository [1]. I was unable
to build the avalon-excalibur/component repository using maven -- I'm
not too familiar with it and didn't get very far (it just built empty jars).
Does anyone know what I can do to get this working again?
cheers,
-steve
[1]
http://cvs.apache.org/viewcvs.cgi/avalon-sandbox/excalibur-old-materials/component/src/java/org/apache/avalon/excalibur/testcase/?hideattic=0#dirlist
Re: XSP "official" position
Posted by Joerg Heinicke <jh...@virbus.de>.
On 22.11.2003 03:49, Vadim Gritsenko wrote:
> Joerg Heinicke wrote:
>
>> (By the way, the simplification to
>>
>> <xsp:logic>
>> if (somecondition()) {
>> <true_tag/>
>> } else {
>> <false_tag/>
>> }
>> </xsp:logic>
>>
>> is exactly what does not work at Cocoon and was the reason for the
>> problem at http://marc.theaimsgroup.com/?t=106931803600003&r=1&w=2.)
>
>
> It *does* work. Everytime. Try it, if you do not believe me.
>
> PS Do not forget that <xsp:expr> must be used in content mode, and not
> in language mode; to switch to content mode from the language mode you
> either (a) open a tag, (b) use <xsp:content> if you don't want a tag.
Argh. It was really to late to write mails :-) I mixed the situation of
the problem (<xsp:expr/>) with the above (any XML). Sorry for the noise.
> PPS Answering your question in the [1], here is trivial and commonly
> used use case:
> String s = <xsp-request:get-parameter name="name"/>;
> Which is identical to:
> String s = <xsp-expr>request.getParameter("name")</xsp:expr>;
>
> [1] http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=106932338722437&w=2
Thanks for this sample. XSP is really to complex - and so is the
stylesheet ;-) Simply to many special cases.
Joerg
Re: XSP "official" position
Posted by Vadim Gritsenko <va...@verizon.net>.
Joerg Heinicke wrote:
> (By the way, the simplification to
>
> <xsp:logic>
> if (somecondition()) {
> <true_tag/>
> } else {
> <false_tag/>
> }
> </xsp:logic>
>
> is exactly what does not work at Cocoon and was the reason for the
> problem at http://marc.theaimsgroup.com/?t=106931803600003&r=1&w=2.)
It *does* work. Everytime. Try it, if you do not believe me.
PS Do not forget that <xsp:expr> must be used in content mode, and not
in language mode; to switch to content mode from the language mode you
either (a) open a tag, (b) use <xsp:content> if you don't want a tag.
PPS Answering your question in the [1], here is trivial and commonly
used use case:
String s = <xsp-request:get-parameter name="name"/>;
Which is identical to:
String s = <xsp-expr>request.getParameter("name")</xsp:expr>;
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=106932338722437&w=2
Vadim
Re: XSP "official" position
Posted by Matt Sergeant <ma...@sergeant.org>.
On 22 Nov 2003, at 1:56, Joerg Heinicke wrote:
>> This level of change to XSP should be discussed on
>> xsp-dev@xml.apache.org, fwiw. I personally would be against this kind
>> of logic control in XSP. Especially since it's perfectly possible to
>> add this in as a tag library.
>
> I thought this list was dead and removed? Is there any archive
> available about recent discussions? But I understand your concern as
> Cocoon is not the only XSP implementing project.
I think the list is still alive.
> But I don't understand your concern related to this logic control.
What I mean is that I'm worried about turning XSP into a full blown
programming language. It is XML after all - it's the worst possible
syntax for programming in.
>>> Yes, afterwards it's very similar to XSLT or other template
>>> languages as JXTemplate.
>>>
>>> The power of XSP is not XSP itself, but the further abstraction
>>> levels as esql as Leszek pointed out. This would make an XML only
>>> XSP to a really powerful template language in contrary to a
>>> programming language with nasty syntax at the moment.
>> This isn't XSP's fault that it gets (ab)used this way. It's perfectly
>> possible *today* to write XSPs that have no programming code in them.
>
> Might be, but the easier the abuse is, the more it will be abused.
I'm not sure what's more abusive though, conditions in XML with
multiple namespaces or mixing a bit of Java or Perl in to do conditions
(and/or loops). I'm not sold either way, fwiw. I'm just not too keen on
being forced to use XML as a programming language (you are talking
about forcing XSPs to be all XML, right?)
>> If Cocoon makes that hard I would consider it a bug (or at minimum a
>> required feature for making XSP a reasonable framework to work with).
>> Certainly it's very easy in AxKit - you just create a class and tell
>> AxKit what methods are tags (sort of like SiLLy, but easier).
>
> Do you have an example? The XP guide is really short.
Sure. Here's a taglib for getting a cookie:
--BEGIN--
package ExampleCookieTaglib; use base
Apache::AxKit::Language::XSP::TaglibHelper;
@EXPORT_TAGLIB = ('get_cookie($name)');
$NS = 'http://example.com/get-cookie';
sub get_cookie {
my $name = shift;
return Apache::Cookie->fetch->{$name}->value;
}
1;
--END--
(Note this is re-usable outside of XSP pages, which is a very useful
feature for unit testing!)
Now that's callable via:
<cookie:get-cookie name="foo"
xmlns:cookie="http://example.com/get-cookie"/>
or:
<cookie:get-cookie>
<name><xsp:expr>$variable</xsp:expr></name>
</cookie:get-cookie>
or a multitude of other ways (also note that AxKit handled the
translation of get_cookie to get-cookie transparently).
You can output tags of any shape or form using TaglibHelper. This
example just output some character data.
Hope that helps.
Matt.
Re: XSP "official" position
Posted by Joerg Heinicke <jh...@virbus.de>.
On 19.11.2003 10:13, Matt Sergeant wrote:
>>> But in fact it seems like XSP is being disliked by many developers.
>>> And I have to admit: I don't really like much anymore, too. But
>>> the question is whether it is because of the syntax or the heavy
>>> machinery or it's maintainability.
>>
>>
>> IMO it's obvious: the mixture of coding languages (Java + XML) and the
>> mixture of abstraction levels. But this abstraction does not make the
>> coding easier, you have to know the implementation details to work
>> around all possible mistakes: How often it is suggested to have a look
>> at the generated Java files! In general we need a XML only XSP (i.e.
>> without any Java written by hand) with minimum of flow support:
>>
>> <xsp:if>, <xsp:for-each>, etc.
>
>
> This level of change to XSP should be discussed on
> xsp-dev@xml.apache.org, fwiw. I personally would be against this kind of
> logic control in XSP. Especially since it's perfectly possible to add
> this in as a tag library.
I thought this list was dead and removed? Is there any archive available
about recent discussions? But I understand your concern as Cocoon is not
the only XSP implementing project.
But I don't understand your concern related to this logic control. At
the moment you can do everything using the implementing language Java or
JavaScript or Perl or what ever. The above "proposal" would bring this
to a standardized way. It's also in XSLT that I had in mind when writing
the above.
There is also an example on Axkit's XSP guide
(http://axkit.org/wiki/view/AxKit/XSPGuide):
<xsp:logic>
if (somecondition()) {
<xsp:content>
<true_tag/>
</xsp:content>
} else {
<xsp:content>
<false_tag/>
</xsp:content>
}
</xsp:logic>
which can be simplified to
<xsp:when test="somecondition()">
<true_tag/>
</xsp:when>
<xsp:otherwise>
<false_tag/>
</xsp:otherwise>
(By the way, the simplification to
<xsp:logic>
if (somecondition()) {
<true_tag/>
} else {
<false_tag/>
}
</xsp:logic>
is exactly what does not work at Cocoon and was the reason for the
problem at http://marc.theaimsgroup.com/?t=106931803600003&r=1&w=2.)
>> Yes, afterwards it's very similar to XSLT or other template languages
>> as JXTemplate.
>>
>> The power of XSP is not XSP itself, but the further abstraction levels
>> as esql as Leszek pointed out. This would make an XML only XSP to a
>> really powerful template language in contrary to a programming
>> language with nasty syntax at the moment.
>
>
> This isn't XSP's fault that it gets (ab)used this way. It's perfectly
> possible *today* to write XSPs that have no programming code in them.
Might be, but the easier the abuse is, the more it will be abused.
> If
> Cocoon makes that hard I would consider it a bug (or at minimum a
> required feature for making XSP a reasonable framework to work with).
> Certainly it's very easy in AxKit - you just create a class and tell
> AxKit what methods are tags (sort of like SiLLy, but easier).
Do you have an example? The XP guide is really short.
Joerg
Re: XSP "official" position
Posted by Matt Sergeant <ma...@sergeant.org>.
On 18 Nov 2003, at 13:57, Joerg Heinicke wrote:
>> But in fact it seems like XSP is being disliked by many developers.
>> And I have to admit: I don't really like much anymore, too. But
>> the question is whether it is because of the syntax or the heavy
>> machinery or it's maintainability.
>
> IMO it's obvious: the mixture of coding languages (Java + XML) and the
> mixture of abstraction levels. But this abstraction does not make the
> coding easier, you have to know the implementation details to work
> around all possible mistakes: How often it is suggested to have a look
> at the generated Java files! In general we need a XML only XSP (i.e.
> without any Java written by hand) with minimum of flow support:
>
> <xsp:if>, <xsp:for-each>, etc.
This level of change to XSP should be discussed on
xsp-dev@xml.apache.org, fwiw. I personally would be against this kind
of logic control in XSP. Especially since it's perfectly possible to
add this in as a tag library.
> Yes, afterwards it's very similar to XSLT or other template languages
> as JXTemplate.
>
> The power of XSP is not XSP itself, but the further abstraction levels
> as esql as Leszek pointed out. This would make an XML only XSP to a
> really powerful template language in contrary to a programming
> language with nasty syntax at the moment.
This isn't XSP's fault that it gets (ab)used this way. It's perfectly
possible *today* to write XSPs that have no programming code in them.
If Cocoon makes that hard I would consider it a bug (or at minimum a
required feature for making XSP a reasonable framework to work with).
Certainly it's very easy in AxKit - you just create a class and tell
AxKit what methods are tags (sort of like SiLLy, but easier).
Matt.
Re: XSP "official" position
Posted by Joerg Heinicke <jh...@virbus.de>.
On 18.11.2003 15:47, Vadim Gritsenko wrote:
>>> XSP leaves room for heavy abuse! I guess that's the major problems.
>>> ...plus that debugging is a pain :)
>>
>> Exactly, we must do it impossible to abuse it :-) Going towards an XML
>> only template language would also allow to have an interpreter instead
>> of compiling transformed java files.
>
> May be you want to resurrect sll [1]? :)
Hmm, no. I want to start at another point, at the lowest level. No Java
at all in a pure XSP file (without any extension, so any logicsheet).
For avoiding exactly such an error as [1]. Or the bugfix for
xsp:attribute handling [2]. At the moment we can not fix it, because XSP
code is to "flexible", it allows additional startElement()s as you
showed in your comment at this bug. And you never get it fixed
appropriately when you mix abstraction levels or different coding
languages (to be proven).
But if you know all the possible things that can occur, you can provide
a working implementation of the transformation or even in interpreter.
[1] http://marc.theaimsgroup.com/?t=106931803600003&r=1&w=2
[2] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15841
Re: XSP "official" position
Posted by Vadim Gritsenko <va...@verizon.net>.
Joerg Heinicke wrote:
> Torsten Curdt wrote:
>
>> XSP leaves room for heavy abuse! I guess that's the major problems.
>> ...plus that debugging is a pain :)
>
>
> Exactly, we must do it impossible to abuse it :-) Going towards an XML
> only template language would also allow to have an interpreter instead
> of compiling transformed java files.
May be you want to resurrect sll [1]? :)
[1]
http://cocoon.apache.org/2.1/userdocs/xsp/logicsheet-concepts.html#The+SiLLy+Logicsheet+Language
Vadim
Re: XSP "official" position
Posted by Joerg Heinicke <jh...@virbus.de>.
Torsten Curdt wrote:
>>> If you wanna compare you need to compare Flow vs. Actions and XSP vs.
>>> Transformers (or other server pages / templating approaches).
>>
>>
>>
>> The discussion really takes a strange way when comparing these both
>> concepts.
>
>
> ...not any stranger than comparing Flow vs. XSP ;)
Flow vs. XSP was actually what I meant.
>> IMO it's obvious: the mixture of coding languages (Java + XML) and the
>> mixture of abstraction levels. But this abstraction does not make the
>> coding easier, you have to know the implementation details to work
>> around all possible mistakes: How often it is suggested to have a look
>> at the generated Java files! In general we need a XML only XSP (i.e.
>> without any Java written by hand) with minimum of flow support:
>>
>> <xsp:if>, <xsp:for-each>, etc.
>
>
> ...because it should only be used as view. agreed
>
>> Yes, afterwards it's very similar to XSLT or other template languages
>> as JXTemplate.
>>
>> The power of XSP is not XSP itself, but the further abstraction levels
>> as esql as Leszek pointed out. This would make an XML only XSP to a
>> really powerful template language in contrary to a programming
>> language with nasty syntax at the moment.
>
>
> ...well, totally agree. But that's only a question how it used - isn't
> it? XSP leaves room for heavy abuse! I guess that's the major problems.
> ...plus that debugging is a pain :)
Exactly, we must do it impossible to abuse it :-) Going towards an XML only
template language would also allow to have an interpreter instead of
compiling transformed java files.
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
joerg.heinicke@virbus.de
www.virbus.de
Re: XSP "official" position
Posted by Torsten Curdt <tc...@vafer.org>.
>> If you wanna compare you need to compare Flow vs. Actions and XSP vs.
>> Transformers (or other server pages / templating approaches).
>
>
> The discussion really takes a strange way when comparing these both
> concepts.
...not any stranger than comparing Flow vs. XSP ;)
> IMO it's obvious: the mixture of coding languages (Java + XML) and the
> mixture of abstraction levels. But this abstraction does not make the
> coding easier, you have to know the implementation details to work
> around all possible mistakes: How often it is suggested to have a look
> at the generated Java files! In general we need a XML only XSP (i.e.
> without any Java written by hand) with minimum of flow support:
>
> <xsp:if>, <xsp:for-each>, etc.
...because it should only be used as view. agreed
> Yes, afterwards it's very similar to XSLT or other template languages as
> JXTemplate.
>
> The power of XSP is not XSP itself, but the further abstraction levels
> as esql as Leszek pointed out. This would make an XML only XSP to a
> really powerful template language in contrary to a programming language
> with nasty syntax at the moment.
...well, totally agree. But that's only a question how it used - isn't
it? XSP leaves room for heavy abuse! I guess that's the major problems.
...plus that debugging is a pain :)
--
Torsten
Re: XSP "official" position
Posted by Joerg Heinicke <jh...@virbus.de>.
Torsten Curdt wrote:
> Gianugo Rabellino wrote:
>
>> Interesting comments here at ApacheCon. Some users are still convinced
>> that we're pushing XSP as the prominent way to build interactive stuff
>> and web applications. Actually on the site there is no particular
>> endorsement of XSP, but there not either a word of warning about this
>> approach being "deprecated" in favor of the flow idea. I do think that
>> it would be nice to put some carefully thought out phrasing on the
>> main XSP page stating that, while still supported, we do think that
>> there are now better alternatives for dynamic websites/applications.
>>
>> WDYT?
>
>
> Hah... I don't think we should bring up a Flow vs. XSP discussion.
> That's comparing pears with apples (not the ones in the CVS or the
> one you are reading this on ;)
>
> XSP and Flow have different concerns! XSP is a serverpage - more kind of
> a view while Flow is more like a controller.
>
> If you wanna compare you need to compare Flow vs. Actions and XSP vs.
> Transformers (or other server pages / templating approaches).
The discussion really takes a strange way when comparing these both concepts.
> But in fact it seems like XSP is being disliked by many developers.
> And I have to admit: I don't really like much anymore, too. But
> the question is whether it is because of the syntax or the heavy
> machinery or it's maintainability.
IMO it's obvious: the mixture of coding languages (Java + XML) and the
mixture of abstraction levels. But this abstraction does not make the coding
easier, you have to know the implementation details to work around all
possible mistakes: How often it is suggested to have a look at the generated
Java files! In general we need a XML only XSP (i.e. without any Java written
by hand) with minimum of flow support:
<xsp:if>, <xsp:for-each>, etc.
Yes, afterwards it's very similar to XSLT or other template languages as
JXTemplate.
The power of XSP is not XSP itself, but the further abstraction levels as
esql as Leszek pointed out. This would make an XML only XSP to a really
powerful template language in contrary to a programming language with nasty
syntax at the moment.
Joerg
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
joerg.heinicke@virbus.de
www.virbus.de
Re: XSP "official" position
Posted by Torsten Curdt <tc...@vafer.org>.
Gianugo Rabellino wrote:
> Interesting comments here at ApacheCon. Some users are still convinced
> that we're pushing XSP as the prominent way to build interactive stuff
> and web applications. Actually on the site there is no particular
> endorsement of XSP, but there not either a word of warning about this
> approach being "deprecated" in favor of the flow idea. I do think that
> it would be nice to put some carefully thought out phrasing on the main
> XSP page stating that, while still supported, we do think that there are
> now better alternatives for dynamic websites/applications.
>
> WDYT?
Hah... I don't think we should bring up a Flow vs. XSP discussion.
That's comparing pears with apples (not the ones in the CVS or the
one you are reading this on ;)
XSP and Flow have different concerns! XSP is a serverpage - more kind of
a view while Flow is more like a controller.
If you wanna compare you need to compare Flow vs. Actions and XSP vs.
Transformers (or other server pages / templating approaches).
But in fact it seems like XSP is being disliked by many developers.
And I have to admit: I don't really like much anymore, too. But
the question is whether it is because of the syntax or the heavy
machinery or it's maintainability.
It's very easy to come up with some quick-and-dirty pages with XSP
but if you put too much logic in it becomes a PITA. But I just don't
see how we could deprecate it ...in favor of what?
Do we really want to force or feature a certain templating approach?
my 2 cents
--
Torsten
Re: XSP "official" position
Posted by Giacomo Pati <gi...@apache.org>.
Gianugo Rabellino wrote:
> Interesting comments here at ApacheCon. Some users are still convinced
> that we're pushing XSP as the prominent way to build interactive stuff
> and web applications. Actually on the site there is no particular
> endorsement of XSP, but there not either a word of warning about this
> approach being "deprecated" in favor of the flow idea. I do think that
> it would be nice to put some carefully thought out phrasing on the main
> XSP page stating that, while still supported, we do think that there are
> now better alternatives for dynamic websites/applications.
>
> WDYT?
An absolute +1 here
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
Re: XSP "official" position
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Steven Noels dijo:
> Antonio Gallardo wrote:
>
>> This is why I am working 10-30 hours every day.
>
> Wow. I sometimes would like to be able to work 24+ hours a day: can you
> share your secret with us? ;-)
Easy don't sleep in all this time and work this time. I wrote
intentionally this values, because at my current rithm of working I cannot
see when a day earth day start and when it end. I just see how long I am
up after sleep. I hope it would soon end. ;-D
Best Regards,
Antonio Gallardo
[very OT] Re: XSP "official" position
Posted by Leszek Gawron <ou...@wlkp.org>.
On Wed, Nov 19, 2003 at 05:11:06PM -0500, Vadim Gritsenko wrote:
> Steven Noels wrote:
>
> >Antonio Gallardo wrote:
> >
> >>This is why I am working 10-30 hours every day.
> >
> >
> >Wow. I sometimes would like to be able to work 24+ hours a day: can
> >you share your secret with us? ;-)
>
>
> He has his sleep removed [1] ...
>
> Vadim
>
> [1] Reference to one of the recent episodes of "Angel", where guy's
> sleep was removed and placed into the jar.
hmmm ... seems that I am not the only adult watching BTVS and Angel :)
ouzo
--
__
| / \ | Leszek Gawron // \\
\_\\ //_/ ouzo@wlkp.org _\\()//_
.'/()\'. Phone: +48(501)720812 / // \\ \
\\ // recursive: adj; see recursive | \__/ |
Re: XSP "official" position
Posted by Vadim Gritsenko <va...@verizon.net>.
Steven Noels wrote:
> Antonio Gallardo wrote:
>
>> This is why I am working 10-30 hours every day.
>
>
> Wow. I sometimes would like to be able to work 24+ hours a day: can
> you share your secret with us? ;-)
He has his sleep removed [1] ...
Vadim
[1] Reference to one of the recent episodes of "Angel", where guy's
sleep was removed and placed into the jar.
Re: XSP "official" position
Posted by Steven Noels <st...@outerthought.org>.
Antonio Gallardo wrote:
> This is why I am working 10-30 hours every day.
Wow. I sometimes would like to be able to work 24+ hours a day: can you
share your secret with us? ;-)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
RE: XSP "official" position
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
David Rogers dijo:
>
>
> Regarding the comment on needing English skills...I can help out there.
> I fancy my self a bit of a tech writer. I have "fixed" just a bit of
> snuff in the wiki but don't want to write anything there that is
> incorrect.
Nice. You can ask for help in the lists when you are not sure of
something. This is how I imrpoved this doc with new tags:
http://wiki.cocoondev.org/Wiki.jsp?page=XSPSyntax
> I bet there are a few others that could help as well.
I think so.
> I am fairly knowledgeable in java/xml/xslt but fairly new to cocoon and
> oss.
Every help is always welcome! :-D
> I would gladly work with those more knowledgeable in cocoon
> to clean up/flesh out some of the existing docs and even create
> some new ones.
>
> (for example I'm kind of interested in the error handling right now
> ...hint
> hint).
What problem you have with it? I am currently very very busy and sometimes
does not read all the mails. Sorry for that. I have a really killer
endline. This is why I am working 10-30 hours every day. But check this:
http://wiki.cocoondev.org/Wiki.jsp?page=ErrorHandling
>
> Also...
> I was thinking it would be nice to just move the "User Guide" on the
> main site to the wiki and basically combine it with the "Cocoon Guide".
> I find it a bit confusing having the two sources, and having to memorize
> which docs are where. Actually, I guess the whole "Documentation" Section
> on the main site could go to the wiki.
Thanks for your reply.
We are know and aware of the documentation problems and what we can do to
solve this PITA. Currently, there is an interesting idea from Stefano:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106691291922337&w=2
> If you have something written (in english!) I can proof read it for you
> and send it back with questions.
Thanks for the offer. I take you proposal. Currently, I have not any
written doc. But I will need to write a how-to for OJB soon. Currently, I
use wiki because it is easy.
> Alternitively, I can just start asking the list whatever questions I am
> having
> and make documentation for the wiki out of the replies.
This is a good idea. Another good source of info are the mailarchives.
There is really very nice ideas and descriptions. We know is very dificult
to harvest the good stuff from them.
Best Regards,
Antonio Gallardo
Re: XSP "official" position
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Tony Collen dijo:
> Not their fault... our docs aren't the shining model of project
> documentation :) I was reading a weblog of a guy who had really hard
> problems getting Cocoon up and running, and he mentioned our docs suck.
> I'm aware of this, as I'm sure everyone else here is.
>
> Another problem is that IMO we need more articles written and published
> on other sites (i.e. XML.com). Getting some docs written up on our site
> is good, but getting exposure elsewhere is crucial.
>
> We need marketing! :)
Yep, I agree. And I think people with more english skills can help us
here. Sometimes people does not realize how hard can be english writing
for some of us.
>>>Actually on the site there is no particular
>>>endorsement of XSP, but there not either a word of warning about this
>>>approach being "deprecated" in favor of the flow idea.
>
> We need to figure something out with the docs, we're rapidly gaining
> water in the hull and sinking fast.
>
> <snip/>
>
>> I think we will continue supporting XSP because Cocoon can be used as
>> Web
>> publishing framework or a Webapp framework. Also XSP is a good entry
>> point
>> for many people from the ASP, PHP world. They feels like fish in the
>> water
>> with XSP. :-D
>
> I think XSP is an OK jumping-off-point for people wanting to write their
> own custom Generators. However, learning XSP and then learning how to
> write a custom Generator is probably the same amount of work (maybe I am
> wrong).
Hmm. As you pointed before there are alternative generators. I never wrote
a generator in my life. I use:
jx generator and file generator. Before I used XSP generator. Now I am
avoiding use XSP generator at all.
>> I really no wonder why peope still think XSP is the great Gig in the
>> Cocoon town, because if you google around you will feel this is the way
>> Cocoon goes. To be honest I don't google about this for a long time but
>> still early this year this was the tendency.
> It's probably got more attention because it's a TLA and sounds like ASP
> or PHP or JSP. XSP.. X? Cool! "Flow" just doesn't have that catchy
> ring to it. But that is not a problem I think.
Nope. I think, It is simply, because it is older than the others.
Best Regards,
Antonio Gallardo
Re: XSP "official" position
Posted by Tony Collen <co...@umn.edu>.
Antonio Gallardo wrote:
> Gianugo Rabellino dijo:
>
>>Interesting comments here at ApacheCon. Some users are still convinced
>>that we're pushing XSP as the prominent way to build interactive stuff
>>and web applications.
>
>
> Incredible enough! 8-0
> BTW, tell then they are totally outdated. :-D
Not their fault... our docs aren't the shining model of project
documentation :) I was reading a weblog of a guy who had really hard
problems getting Cocoon up and running, and he mentioned our docs suck.
I'm aware of this, as I'm sure everyone else here is.
Another problem is that IMO we need more articles written and published
on other sites (i.e. XML.com). Getting some docs written up on our site
is good, but getting exposure elsewhere is crucial.
We need marketing! :)
Tony
>>Actually on the site there is no particular
>>endorsement of XSP, but there not either a word of warning about this
>>approach being "deprecated" in favor of the flow idea.
We need to figure something out with the docs, we're rapidly gaining
water in the hull and sinking fast.
<snip/>
> I think we will continue supporting XSP because Cocoon can be used as Web
> publishing framework or a Webapp framework. Also XSP is a good entry point
> for many people from the ASP, PHP world. They feels like fish in the water
> with XSP. :-D
I think XSP is an OK jumping-off-point for people wanting to write their
own custom Generators. However, learning XSP and then learning how to
write a custom Generator is probably the same amount of work (maybe I am
wrong).
> I really no wonder why peope still think XSP is the great Gig in the
> Cocoon town, because if you google around you will feel this is the way
> Cocoon goes. To be honest I don't google about this for a long time but
> still early this year this was the tendency.
It's probably got more attention because it's a TLA and sounds like ASP
or PHP or JSP. XSP.. X? Cool! "Flow" just doesn't have that catchy
ring to it. But that is not a problem I think.
Tony