Re: Generating XML - Design decisions

2004-04-23 Thread beyaNet Consultancy
On 23 Apr 2004, at 19:58, Alex Romayev wrote:

JXTemplateGenerator is not Cacheable.
Is any work being done on this???

Peter

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


Re: Generating XML - Design decisions

2004-04-23 Thread Alex Romayev
One issue with the combination below is that
JXTemplateGenerator is not Cacheable.  Implementing a
custom generator may be a bit more effort, but can pay
back in performance.

Le 23 avr. 04, à 14:15, Ugo Cei a écrit :
 
> > ...Persistence layer: OJB, Hibernate or similar
> O/R mapping tool
> > Business logic: Java classes
> > Controller: Flowscript
> > View: JXTemplateGenerator or Velocity
> >
> >
> > Don't let anyone try to convince you that you can
> find a better 
> > combination for Cocoon. You won't


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



RE: Generating XML - Design decisions

2004-04-23 Thread David Leangen

> > Persistence layer: OJB, Hibernate or similar O/R mapping tool
> > Business logic: Java classes
> > Controller: Flowscript
> > View: JXTemplateGenerator or Velocity
>
> Ditto to all of that.  I think this is really the killer combo!

Since we're on the subject, I'm interested in hearing everybody's thoughts
on using Struts for the controller, so the above would be:

Persistence layer: OJB, Hibernate or similar O/R mapping tool
Business logic: Java classes
Controller: Struts
View: JXTemplateGenerator or Velocity


Thoughts? Personal experiences?


Dave



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



Re: Generating XML - Design decisions

2004-04-23 Thread Mark Lundquist
On Apr 23, 2004, at 5:15 AM, Ugo Cei wrote:

Hildebrandt, Ole wrote:
I am fairly new to cocoon and I am planning to use it for a quite big
website. I keep thinking what the best way is to genrate XML from a
database.
Persistence layer: OJB, Hibernate or similar O/R mapping tool
Business logic: Java classes
Controller: Flowscript
View: JXTemplateGenerator or Velocity
Ditto to all of that.  I think this is really the killer combo!

~mark

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


Re: Generating XML - Design decisions

2004-04-23 Thread Ugo Cei
Bertrand Delacretaz wrote:
People might not realize that for Cocoon a 10'000-pages website 
generated from a read-only database is not that "big" ;-)
Well, just this morning I generated a static snapshot of a Cocoon 
website totaling a little more than 9800 pages ;-). Most of them are 
coming from SQL queries.

Actually, the site is just an XSP-based prototype, but for the "real 
thing", which will be dynamically generated, since the number of 
possible pages will grow exponentially, we are designing an 
Hibernate/Flowscript/JXTG application.

	Ugo

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


Re: Generating XML - Design decisions

2004-04-23 Thread Leon Widdershoven
Ugo Cei wrote:

Leon Widdershoven wrote:

It is, of course, strongly recommended that you have some knowledge
about java if you're going to build a O/R bridge. But not that much.


I would strongly advise against *building* an O/R bridge. It's not 
easy at all to get it right and there are many good products 
available, both Open Source and commercial.

Ugo


With building a bridge I meant using OJB or hibernate, use the 
associated tools to generate the classes, perhaps
generate a wrapper for more complicated business logc (by e.g. 
inheriting the generated classes). I did not
mean creating yet another O/R toolkit, nor, for a big database, 
generating the classes by hand.

but AFAIK there is no ready made solution which also thinks out the 
business logic:)

Leon

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


Re: Generating XML - Design decisions

2004-04-23 Thread Bertrand Delacretaz
Le 23 avr. 04, à 15:52, Ugo Cei a écrit :

...I more or less assumed that a "big" site would also be a complex 
web site, with a complex information architecture, data model and 
interaction
Sure...but the perception of what is "big" varies widely between people 
and projects!

People might not realize that for Cocoon a 10'000-pages website 
generated from a read-only database is not that "big" ;-)

-Bertrand



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


Re: Generating XML - Design decisions

2004-04-23 Thread Ugo Cei
Bertrand Delacretaz wrote:
It mostly depends on what a "quite big web site" is.  Generating a 
couple hundred thousand pages out of a database with direct SQL would be 
no problem if the database schema is a simple one and if you're doing 
"read-only" stuff, only generating XML out of the database, not writing 
to it.
I more or less assumed that a "big" site would also be a complex web 
site, with a complex information architecture, data model and interaction.

Of course, it might be that this assumption is totally unwarranted ;-).

	Ugo

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


Re: Generating XML - Design decisions

2004-04-23 Thread Philippe Guillard
Hi,

I agree with all that has been said here, and as a newbie i can tell
XSP+SQL for reading is really easy and OJB not so hard if like me you
use 10% of its incredible capabilities.
But!!: speaking about full XML website, i'm surprised to see nobody
mentioned native XML databases and XML:DB?

Phil

On Fri, 2004-04-23 at 20:01, Leon Widdershoven wrote:
> You could try an Object/Relational bridge, like OJB or Hibernate,
> and combine it with Flowscript.
> You can use the JX generator to write bean information in the pages
> dynamically (using, of course, flowscript and cocoon.sendPage)
> 
> There are tutorials and introductions on  the WIKI on that subject.
> 
> It is, of course, strongly recommended that you have some knowledge
> about java if you're going to build a O/R bridge. But not that much.
> 
> Javascript (flowscript) is, as I understand, at present the recommended
> way to write apps. It is also not hard to learn and Java classes
> containing business logic can be called from withing the Javascript
> interpreter (Mozilla Rhino).
> 
> OJB and Hibertnate do require some investment in time to get to know it.
> I think a day full time playing is not too much, and will give you a
> feeling for it.
> 
> Please visit the cocoon wiki and look at the howto's for more info.
> 
> Hope that helped a bit.
> 
> Leon
> 
> Hildebrandt, Ole wrote:
> > Hi,
> > 
> > I am fairly new to cocoon and I am planning to use it for a quite big
> > website. I keep thinking what the best way is to genrate XML from a
> > database.
> > 
> > - XSP seems too complicated and limited and there is no knowledge in the
> > developer-team available
> > - JSP seems okay, many developers are familiar with it, but are there any
> > drawbacks regarding performance (I think JSP-Generator is not cachable, is
> > it?) or other things?
> > - Writing a new Generator seems to be a too much, and not very practical in
> > development since you have to recompile it all the time and cannot make
> > changes at runtime
> > - Doing it with SQL- and XSLT-Transformers? Not so nice, since IMO the code
> > for implementing the logic is spread over too many files (Correct me if i am
> > wrong)
> > 
> > It would be really helpful if someone had a pice of advise or any experience
> > what approach pays off best
> > 
> > Regards
> > 
> > Ole
> > 
> > 
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


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



Re: AW: Generating XML - Design decisions

2004-04-23 Thread Ugo Cei
Hildebrandt, Ole wrote:
Hi,

Thanks for all the replies. I will have a look at the flowscript, which i
ommitted so far, as I thought it is not essential for builing a website that
has fairly any user-interactive processes, but is just barely an
information-delivery-website.
I have been developing some MVC-Webapps with Servlets and JSP and I was
hoping to simply adopt this pattern to cocoon (Sitemap == Conroller, XSP or
JSP = View, native Java-Class called within views = Pull-Modell). With this
approch I could encapsulate all the business-logic in the modell, the
sitemap would be responsible for calling the correct view and the views
would grep the data from the modell by calling the appropriate method and
just perform the Logic for presentation. Is this applicable for cocoon or am
I going in the wrong direction with this idea?
Personally, I don't like Pull-Model and could point you to this paper 
[1], where the issue is argued much better than I could hope to do here.

However, there's nothing in Cocoon that would stop you from doing that, 
even if I would rather use JXTemplate or Velocity as template engines, 
and avoid XSP or JSP.

	Ugo

[1] http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf

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


Re: Generating XML - Design decisions

2004-04-23 Thread Bertrand Delacretaz
Le 23 avr. 04, à 14:15, Ugo Cei a écrit :

...Persistence layer: OJB, Hibernate or similar O/R mapping tool
Business logic: Java classes
Controller: Flowscript
View: JXTemplateGenerator or Velocity
Don't let anyone try to convince you that you can find a better 
combination for Cocoon. You won't
But some of us (some of me at least ;-) still think that direct SQL 
*might* make sense for the database access layer depending on your app, 
environment and skills.

I'm 100% with Ugo in the general case, but I wouldn't want us to "lose" 
users because they think they must learn too much stuff to be 
productive with Cocoon.

It mostly depends on what a "quite big web site" is.  Generating a 
couple hundred thousand pages out of a database with direct SQL would 
be no problem if the database schema is a simple one and if you're 
doing "read-only" stuff, only generating XML out of the database, not 
writing to it.

Of course, as soon as you start talking transactional processes and/or 
complex databases, a persistence layer like Hibernate or OJB is way 
better in terms of clean structure and maintainability.

Unfortunately the situation for direct SQL with Cocoon is suboptimal 
(IMHO) at the moment: the components mentioned by Ugo are the latest 
and greatest stuff, all very well designed and functional, but the 
"direct SQL" stuff (ESQL and SQLTransformer) is not as "modern" in 
concept or as "nice" to write code for. The Groovy-based SQL query 
stuff could improve things, at least on the "nice to write" front, but 
it's only vaporware ATM (fairly hot vapor though ;-)

Hope this helps, trying not to add to the potential confusion here...

-Bertrand

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


AW: Generating XML - Design decisions

2004-04-23 Thread Hildebrandt, Ole
Hi,

Thanks for all the replies. I will have a look at the flowscript, which i
ommitted so far, as I thought it is not essential for builing a website that
has fairly any user-interactive processes, but is just barely an
information-delivery-website.

I have been developing some MVC-Webapps with Servlets and JSP and I was
hoping to simply adopt this pattern to cocoon (Sitemap == Conroller, XSP or
JSP = View, native Java-Class called within views = Pull-Modell). With this
approch I could encapsulate all the business-logic in the modell, the
sitemap would be responsible for calling the correct view and the views
would grep the data from the modell by calling the appropriate method and
just perform the Logic for presentation. Is this applicable for cocoon or am
I going in the wrong direction with this idea?

Kind Regards

Ole


> -Ursprüngliche Nachricht-
> Von: Leon Widdershoven [mailto:[EMAIL PROTECTED] 
> Gesendet: Freitag, 23. April 2004 14:01
> An: [EMAIL PROTECTED]
> Betreff: Re: Generating XML - Design decisions
> 
> 
> You could try an Object/Relational bridge, like OJB or 
> Hibernate, and combine it with Flowscript. You can use the JX 
> generator to write bean information in the pages dynamically 
> (using, of course, flowscript and cocoon.sendPage)
> 
> There are tutorials and introductions on  the WIKI on that subject.
> 
> It is, of course, strongly recommended that you have some 
> knowledge about java if you're going to build a O/R bridge. 
> But not that much.
> 
> Javascript (flowscript) is, as I understand, at present the 
> recommended way to write apps. It is also not hard to learn 
> and Java classes containing business logic can be called from 
> withing the Javascript interpreter (Mozilla Rhino).
> 
> OJB and Hibertnate do require some investment in time to get 
> to know it. I think a day full time playing is not too much, 
> and will give you a feeling for it.
> 
> Please visit the cocoon wiki and look at the howto's for more info.
> 
> Hope that helped a bit.
> 
> Leon
> 
> Hildebrandt, Ole wrote:
> > Hi,
> > 
> > I am fairly new to cocoon and I am planning to use it for a 
> quite big 
> > website. I keep thinking what the best way is to genrate XML from a 
> > database.
> > 
> > - XSP seems too complicated and limited and there is no 
> knowledge in 
> > the developer-team available
> > - JSP seems okay, many developers are familiar with it, but 
> are there 
> > any drawbacks regarding performance (I think JSP-Generator is not 
> > cachable, is
> > it?) or other things?
> > - Writing a new Generator seems to be a too much, and not 
> very practical in
> > development since you have to recompile it all the time and 
> cannot make
> > changes at runtime
> > - Doing it with SQL- and XSLT-Transformers? Not so nice, 
> since IMO the code
> > for implementing the logic is spread over too many files 
> (Correct me if i am
> > wrong)
> > 
> > It would be really helpful if someone had a pice of advise or any 
> > experience what approach pays off best
> > 
> > Regards
> > 
> > Ole
> > 
> > 
> > 
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

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



Re: Generating XML - Design decisions

2004-04-23 Thread Ugo Cei
Leon Widdershoven wrote:
It is, of course, strongly recommended that you have some knowledge
about java if you're going to build a O/R bridge. But not that much.
I would strongly advise against *building* an O/R bridge. It's not easy 
at all to get it right and there are many good products available, both 
Open Source and commercial.

	Ugo

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


Re: Generating XML - Design decisions

2004-04-23 Thread Ugo Cei
Hildebrandt, Ole wrote:
I am fairly new to cocoon and I am planning to use it for a quite big
website. I keep thinking what the best way is to genrate XML from a
database.
Persistence layer: OJB, Hibernate or similar O/R mapping tool
Business logic: Java classes
Controller: Flowscript
View: JXTemplateGenerator or Velocity
Don't let anyone try to convince you that you can find a better 
combination for Cocoon. You won't.

	Ugo

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


Re: Generating XML - Design decisions

2004-04-23 Thread Martin Holz
[EMAIL PROTECTED] writes:

> Hi,
> I also ask me such a question when I start with Cocoon.
> For me, I think that  :
> 1) You have to use as much as possible the existing generator ans simply pass
> them parameters.

Reusing existing components is fine, but there is a limit. If you 
need complicated transformations to postprocess the output, you should
consider writing a custom generator.

Martin 


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



Re: Generating XML - Design decisions

2004-04-23 Thread Geert Van Damme

Hey,

I think you should consider anyway using XSP. It isn't hard to
learn/use (actually to get data from database and convert it to XML it
is really simple !!) and the performance should be good (use caching if
possible).
We use XSP's for data extraction, which also consists of generating
(large) XML files from database, and Cocoon/XSP has made this really
simple.
You can use some java code inside the XSP if you need some extra
processing, so XSP isn't that limited...

Hope this helps !

Regards,
Geert


>>> [EMAIL PROTECTED] 04/23/04 12:28pm >>>
Hi,

I am fairly new to cocoon and I am planning to use it for a quite big
website. I keep thinking what the best way is to genrate XML from a
database.

- XSP seems too complicated and limited and there is no knowledge in
the
developer-team available
- JSP seems okay, many developers are familiar with it, but are there
any
drawbacks regarding performance (I think JSP-Generator is not cachable,
is
it?) or other things?
- Writing a new Generator seems to be a too much, and not very
practical in
development since you have to recompile it all the time and cannot
make
changes at runtime
- Doing it with SQL- and XSLT-Transformers? Not so nice, since IMO the
code
for implementing the logic is spread over too many files (Correct me if
i am
wrong)

It would be really helpful if someone had a pice of advise or any
experience
what approach pays off best

Regards

Ole



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


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



Re: Generating XML - Design decisions

2004-04-23 Thread Leon Widdershoven
You could try an Object/Relational bridge, like OJB or Hibernate,
and combine it with Flowscript.
You can use the JX generator to write bean information in the pages
dynamically (using, of course, flowscript and cocoon.sendPage)
There are tutorials and introductions on  the WIKI on that subject.

It is, of course, strongly recommended that you have some knowledge
about java if you're going to build a O/R bridge. But not that much.
Javascript (flowscript) is, as I understand, at present the recommended
way to write apps. It is also not hard to learn and Java classes
containing business logic can be called from withing the Javascript
interpreter (Mozilla Rhino).
OJB and Hibertnate do require some investment in time to get to know it.
I think a day full time playing is not too much, and will give you a
feeling for it.
Please visit the cocoon wiki and look at the howto's for more info.

Hope that helped a bit.

Leon

Hildebrandt, Ole wrote:
Hi,

I am fairly new to cocoon and I am planning to use it for a quite big
website. I keep thinking what the best way is to genrate XML from a
database.
- XSP seems too complicated and limited and there is no knowledge in the
developer-team available
- JSP seems okay, many developers are familiar with it, but are there any
drawbacks regarding performance (I think JSP-Generator is not cachable, is
it?) or other things?
- Writing a new Generator seems to be a too much, and not very practical in
development since you have to recompile it all the time and cannot make
changes at runtime
- Doing it with SQL- and XSLT-Transformers? Not so nice, since IMO the code
for implementing the logic is spread over too many files (Correct me if i am
wrong)
It would be really helpful if someone had a pice of advise or any experience
what approach pays off best
Regards

Ole



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


Re: Generating XML - Design decisions

2004-04-23 Thread laurent_rorive

Hi,

I also ask me such a question when I
start with Cocoon.

For me, I think that  :

1) You have to use as much as possible
the existing generator ans simply pass them parameters.
2) If you have database, you can greatly
reduce development time by using XSP and ESQL
3) When there are really specific treatment
or when you want to centralize the XML generation,... you can use generator.

    by example : I use it
to generate information coming from Lotus Notes database because there
are no ODBC link or not performant to Lotus.

Hope it can help

Laurent







"Hildebrandt, Ole" <[EMAIL PROTECTED]>
23/04/2004 12:28
Please respond to users
        
        To:
       [EMAIL PROTECTED]
        cc:
       
        Subject:
       Generating XML - Design decisions


Hi,

I am fairly new to cocoon and I am planning to use it for a quite big
website. I keep thinking what the best way is to genrate XML from a
database.

- XSP seems too complicated and limited and there is no knowledge in the
developer-team available
- JSP seems okay, many developers are familiar with it, but are there any
drawbacks regarding performance (I think JSP-Generator is not cachable,
is
it?) or other things?
- Writing a new Generator seems to be a too much, and not very practical
in
development since you have to recompile it all the time and cannot make
changes at runtime
- Doing it with SQL- and XSLT-Transformers? Not so nice, since IMO the
code
for implementing the logic is spread over too many files (Correct me if
i am
wrong)

It would be really helpful if someone had a pice of advise or any experience
what approach pays off best

Regards

Ole



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




Generating XML - Design decisions

2004-04-23 Thread Hildebrandt, Ole
Hi,

I am fairly new to cocoon and I am planning to use it for a quite big
website. I keep thinking what the best way is to genrate XML from a
database.

- XSP seems too complicated and limited and there is no knowledge in the
developer-team available
- JSP seems okay, many developers are familiar with it, but are there any
drawbacks regarding performance (I think JSP-Generator is not cachable, is
it?) or other things?
- Writing a new Generator seems to be a too much, and not very practical in
development since you have to recompile it all the time and cannot make
changes at runtime
- Doing it with SQL- and XSLT-Transformers? Not so nice, since IMO the code
for implementing the logic is spread over too many files (Correct me if i am
wrong)

It would be really helpful if someone had a pice of advise or any experience
what approach pays off best

Regards

Ole



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