Leon
Too late! I already claimed "POBS" as *my* acronymn!!
;-)
Derek
>>> [EMAIL PROTECTED] 2004/05/09 12:23:08 AM >>>
In response to "Even if you don't use EJB":
Tomcat is often used as the container in which cocoon runs. And as far
as I know (which is
not that far:) tomcat does not do enterp
Hi Derek
Have you seen this implementation of JDO
http://tjdo.sourceforge.net/index.html
TriActive JDO (TJDO)
it's Apache License
Klaus
Derek Hohls wrote:
I just found an interesting quote from a paper on JDO:
http://www.jdocentral.com/pdf/eigner_jdo.pdf
"With the availability of JDO, it makes
Derek Hohls wrote:
I just found an interesting quote from a paper on JDO:
http://www.jdocentral.com/pdf/eigner_jdo.pdf
"With the availability of JDO, it makes you wonder when
and if you would ever need an EJB container at all within your
application architecture if you use it only as a front-en
I just found an interesting quote from a paper on JDO:
http://www.jdocentral.com/pdf/eigner_jdo.pdf
"With the availability of JDO, it makes you wonder when
and if you would ever need an EJB container at all within your
application architecture if you use it only as a front-end
to your database
Le 7 mai 04, à 08:23, Derek Hohls a écrit :
...In the meantime, a tiny question - is it likely
that for most apps; a POB ("plain old bean")
would the most common object that I would
need to be able to understand and know how
to build in order to do the other wonderful
things with Hibernate, flows
Thanks Ugo; I look forward to that.
In the meantime, a tiny question - is it likely
that for most apps; a POB ("plain old bean")
would the most common object that I would
need to be able to understand and know how
to build in order to do the other wonderful
things with Hibernate, flowscript etc
Le 6 mai 04, à 09:44, Derek Hohls a écrit :
Bertand
Is there not a difference between a Java "business
object" (which I assume in a Cocoon app will be a
POJO - even though I do not now know where and
how to create this...) and "data access object" - at
least that what the Core J2EE patterns imply
Bertand
Is there not a difference between a Java "business
object" (which I assume in a Cocoon app will be a
POJO - even though I do not now know where and
how to create this...) and "data access object" - at
least that what the Core J2EE patterns imply
http://java.sun.com/blueprints/corej2eepatt
Derek Hohls wrote:
Ugo
Maybe you could start a "working draft" on the Wiki:
"even the smallest match-flame is a light to the
unenlightened" !
That's an idea, but I still need a few days to have something working.
For starters, I would like to see an example of
what a POJO would/could look like; w
Ugo
Maybe you could start a "working draft" on the Wiki:
"even the smallest match-flame is a light to the
unenlightened" !
For starters, I would like to see an example of
what a POJO would/could look like; where and how
it would/should be placed in a Cocoon app; and how
it is pulled (or pushed??
Derek Hohls wrote:
Right - but I assuming its still handwritten code
and not an existing module in Cocoon - is there
a guide to how to integrate these into Cocoon?
(I wont say "best practice"! ;-)
I don't think there is, it's just a pattern. I'm just starting to
experiment with having my DAOs man
Le 5 mai 04, à 14:35, Derek Hohls a écrit :
Right - but I assuming its still handwritten code
and not an existing module in Cocoon - is there
a guide to how to integrate these into Cocoon?
(I wont say "best practice"! ;-)
You should really get the supersonic block and look at the "bean
editor" ex
Right - but I assuming its still handwritten code
and not an existing module in Cocoon - is there
a guide to how to integrate these into Cocoon?
(I wont say "best practice"! ;-)
>>> [EMAIL PROTECTED] 2004/05/05 02:28:13 PM >>>
Derek Hohls wrote:
> DAO = custom code written in Java?
> or is there
Derek Hohls wrote:
DAO = custom code written in Java?
or is there a module in Cocoon for this?
DAO = generic data access pattern that can be implemented in Java or in
any other OO language.
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
Ugo
-
h, 5. Mai 2004 11:38
> An: [EMAIL PROTECTED]
> Betreff: Re: AW: JXTemplates - what's in a name?
>
>
> ;-) [but lets drop the Generator part - we are not generating
> anything here apart from a view!]
>
> >>> [EMAIL PROTECTED] 2004/05/05 10:
On Wed, 2004-05-05 at 11:34, Derek Hohls wrote:
> Bruno
>
> Thanks for helping clarify this - maybe all this is "obvious"
> to well-seasoned developers, but perhaps not to everyone.
>
> To continue; assuming that inserting database records,
> modifying object models etc does not take place anywh
prüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Auftrag
> von Bruno Dumon
> Gesendet: Dienstag, 4. Mai 2004 20:53
> An: [EMAIL PROTECTED]
> Betreff: Re: JXTemplates - what's in a name?
>
>
> On Tue, 2004-05-04 at 10:39, Derek Hohls wrote:
DAO = custom code written in Java?
or is there a module in Cocoon for this?
>>> [EMAIL PROTECTED] 2004/05/05 12:35:33 PM >>>
Derek Hohls wrote:
> To continue; assuming that inserting database records,
> modifying object models etc does not take place anywhere in
> the pipeline; where *does* it ta
Derek Hohls wrote:
To continue; assuming that inserting database records,
modifying object models etc does not take place anywhere in
the pipeline; where *does* it take place in your application as
a whole - in custom written actions? in the flowscript??
In my case, it happens in DAOs [1] called
o:[EMAIL PROTECTED]
Auftrag
> von Derek Hohls
> Gesendet: Dienstag, 4. Mai 2004 08:31
> An: [EMAIL PROTECTED]
> Betreff: Re: AW: JXTemplates - what's in a name?
>
>
> This sounds great - exactly what I had in mind -
> perhaps "JXStringTemplate" (in deference t
Bruno
Thanks for helping clarify this - maybe all this is "obvious"
to well-seasoned developers, but perhaps not to everyone.
To continue; assuming that inserting database records,
modifying object models etc does not take place anywhere in
the pipeline; where *does* it take place in your applic
its name currently is KISSTemplateGenerator ;-)
> -Ursprungliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Auftrag
> von Derek Hohls
> Gesendet: Dienstag, 4. Mai 2004 08:31
> An: [EMAIL PROTECTED]
> Betreff: Re: AW: JXTemplates - what's in a
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Auftrag
> von Bruno Dumon
> Gesendet: Dienstag, 4. Mai 2004 20:53
> An: [EMAIL PROTECTED]
> Betreff: Re: JXTemplates - what's in a name?
>
>
> On Tue, 2004-05-04 at
On Wed, 2004-05-05 at 08:56, Derek Hohls wrote:
> Bruno
>
> Yes, I suggest you read the paper first before we continue
> the discussion on templates ;-)
>
> In the meantime, perhaps you can expand on why there should
> not be logic in generators such as XSP and JXT and, if not there,
> where it
Bruno
Yes, I suggest you read the paper first before we continue
the discussion on templates ;-)
In the meantime, perhaps you can expand on why there should
not be logic in generators such as XSP and JXT and, if not there,
where it should, in fact, be (short of writing custom Java code
each tim
On Tue, 2004-05-04 at 10:39, Derek Hohls wrote:
> Bruno
>
> I apologise then, if I misunderstood what you said.
>
> I still do not think that we should use the term "template
> generator" in this context. There are "generators" and there
> are "templates" and I don't think their roles should b
Bruno
I apologise then, if I misunderstood what you said.
I still do not think that we should use the term "template
generator" in this context. There are "generators" and there
are "templates" and I don't think their roles should be mixed.
That's why I was arguing for two different "takes" o
On Tue, 2004-05-04 at 08:20, Derek Hohls wrote:
> Well, a template is normally thought of something where you
> have a layout and just "fill in the holes" with data created
> somewhere else, vs a generator whose assignment it is to
> do the data generation in the first place
The result of proc
Gesendet: Montag, 3. Mai 2004 14:23
> An: [EMAIL PROTECTED]
> Betreff: JXTemplates - what's in a name?
>
>
> An April 2004 post pointed me to Terence Parr's article on
"Enforcing
> Strict MV Separation in Template Engine
Terence
Yes, I think your situation is true for a lot of Cocooners; I have
tended
to use XSP because my "use cases" do not require specialised data
generation (as yours seems to) - its mostly just pulling data from a
DB
(see the other thread on this topic). If I can avoid handcoded Java
for
this
Well, a template is normally thought of something where you
have a layout and just "fill in the holes" with data created
somewhere else, vs a generator whose assignment it is to
do the data generation in the first place
I did try to make this distinction clear in the rest of the message
(whic
I'm new to cocoon and JXTs so what I know is only what I have read on
the website and what I've done so far with a cocoon app I've taken over
development of. I will make some general comments on the ideas you've
raised.
I wouldn't get bogged down in the whole "purity" thing with whether or
not
On Mon, 2004-05-03 at 14:22, Derek Hohls wrote:
> An April 2004 post pointed me to Terence Parr's article on "Enforcing
> Strict MV Separation in Template Engines". (see article link at:
> http://www.stringtemplate.org ). This is a fascinating read and, to
> me, a classic in the field.
>
> What
hricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Auftrag
> von Derek Hohls
> Gesendet: Montag, 3. Mai 2004 14:23
> An: [EMAIL PROTECTED]
> Betreff: JXTemplates - what's in a name?
>
>
> An April 2004 post pointed me to Terence Parr's articl
An April 2004 post pointed me to Terence Parr's article on "Enforcing
Strict MV Separation in Template Engines". (see article link at:
http://www.stringtemplate.org ). This is a fascinating read and, to
me, a classic in the field.
What I learnt (amongst other interesting stuff) is that a "true"
35 matches
Mail list logo
