Reinhard Poetz wrote:
snip
I already said in several mails that we should reduce the recommended
options:
1.) Use O/R-mapper if possible
2.) if you only have publishing tasks use the sqlTransformer
3.) If the learning curve for an O/R-mapper is too steep for you take
(In my opinion
Antonio Gallardo wrote:
Reinhard Poetz dijo:
I'm aware of the fact that there are many ways in Cocoon. I think that
we as community should give clear advice what's in our opinion the best
way. If I'm asked I say:
1. Enterprise Level --- O/R-mapping, EJB
2. Simple Database Applications with
Christopher Oliver wrote:
Reinhard Poetz wrote:
snip
I already said in several mails that we should reduce the recommended
options:
1.) Use O/R-mapper if possible
2.) if you only have publishing tasks use the sqlTransformer
3.) If the learning curve for an O/R-mapper is too steep for you take
snip/
But both such cases would be to protect the user, and not to
force users to a certain development model favoured by the
developer. The developer may well be right in his opinions,
but users come from different backgrounds and would not
understand they be limited because their way is not
On 19 Apr 2004, at 11:52, Ugo Cei wrote:
Il giorno 19/apr/04, alle 10:08, Carsten Ziegeler ha scritto:
I have counted +1 from Stefano, Antonio, Reinhard, Ralph and
Gianugo (and myself of course :) )
And we have the concerns from Ugo and Joerg? What do you two
think, now after I could convince
I think (2) can be also be used with O/R mapping tool. Not sure what the
DB component is. In fact (and with my respect to ESQL developers) why
Cocoon will need to build another layer when there is OJB. Remeber OJB
allow you to play at 4 levels:
As a user: Of course you can. The question is
I will not be sure. Writing SQL code is always larger than using O/R
mapping tools and we already know many developers have problem with SQL.
They don't write optimal SQL queries. See slides 10-14:
http://cvs.apache.org/viewcvs.cgi/*checkout*/db-ojb/contrib/ojb-dataccess.pdf
I honestly do not
Reinhard Poetz dijo:
Antonio Gallardo wrote:
Reinhard Poetz dijo:
I'm aware of the fact that there are many ways in Cocoon. I think that
we as community should give clear advice what's in our opinion the best
way. If I'm asked I say:
1. Enterprise Level --- O/R-mapping, EJB
2. Simple
Antonio Gallardo wrote:
Reinhard Poetz dijo:
Antonio Gallardo wrote:
Reinhard Poetz dijo:
I'm aware of the fact that there are many ways in Cocoon. I think that
we as community should give clear advice what's in our opinion the best
way. If I'm asked I say:
1. Enterprise Level
In [1] I suggested that we continue the development of 2.1.x and port
some nice things from the 2.2 branch back as long as they don't create
big incompatibilities.
Now, I started to port back the new environment handling and found out
that it's not that easy :)
In the current 2.2 branch we did
Leon Widdershoven dijo:
I will not be sure. Writing SQL code is always larger than using O/R
mapping tools and we already know many developers have problem with SQL.
They don't write optimal SQL queries. See slides 10-14:
Carsten Ziegeler wrote:
snip/
My opinion is that we should remove deprecated classes (some of them)
in our 2.1.x branch *now* in order to create a smooth transition and
to build a better basis for the future development.
To indicate this, we should update the version number to 2.2 *now* in
the
Reinhard Poetz dijo:
After reading this one question remains: What is the reason why are
*you* interested in Groovy and its SQL support? Which problem do you
want to solve which can't be solved with OJB?
Groovy can help people that don't want to get involved with O/R mapping
tools. They can
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
snip/
My opinion is that we should remove deprecated classes (some
of them)
in our 2.1.x branch *now* in order to create a smooth
transition and to
build a better basis for the future development.
To indicate this, we should
Antonio Gallardo wrote:
Reinhard Poetz dijo:
After reading this one question remains: What is the reason why are
*you* interested in Groovy and its SQL support? Which problem do you
want to solve which can't be solved with OJB?
Groovy can help people that don't want to get involved with
From Jetbrains homepage (the creators of Intellij IDEA):
Fabrique is a Rapid Application Development environment for developing
sophisticated web and enterprise applications.
http://www.jetbrains.com/fabrique/
This hasnt really that much to do with Cocoon but one can dream about a
similar IDE
Reinhard Poetz dijo:
So Groovy becomes yet another alternative for database-based publishing,
doesn't it?
Yep.
Would you recommend it to create web *applications*?
It is just a RT. I don't write a line of code in thatway . But it is in my
long TODO from now. :-D
Best Regards,
Antonio
On Mon, 2004-04-19 at 17:48, Joerg Heinicke wrote:
Marc Portier mpo at outerthought.org writes:
I do propose:
- some refactoring of the kind
- introduce more granular methods
(e.g. to call parseValue() in stead of getValue() in all occasions
where the return is ignored
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
snip/
My opinion is that we should remove deprecated classes (some
of them)
in our 2.1.x branch *now* in order to create a smooth
transition and to
build a better basis for the future
Carsten Ziegeler cziegeler at s-und-n.de writes:
WDYT?
Hmm, sorry, but that's to much confusion IMO. But read on ...
snip what=changes 2.1 = 2.2/
only
if we remove deprecated code, the environment handling can be
improved. Or in other words: backporting to 2.1.x would require to remove
Reinhard Poetz dijo:
IMO we can move on with 2.1.x and remove the deprecated classes if this
is necessary. WDYT?
+1
Best Regards,
Antonio Gallardo
Carsten Ziegeler wrote:
snip /
And in addition, 2.2 would be the first release with the official
cocoon forms version. This alone makes a version change acceptable.
do you already have a timeframe in mind?
(cforms is still unstable, and is IMO not near removing that tag)
WDYT?
in general I'm
Marc Portier wrote:
Carsten Ziegeler wrote:
snip /
And in addition, 2.2 would be the first release with the official
cocoon forms version. This alone makes a version change acceptable.
do you already have a timeframe in mind?
(cforms is still unstable, and is IMO not near
Hunsberger, Peter wrote:
Daniel Fagerstrom [EMAIL PROTECTED] writes:
snip/
I believe OTH that some of the simpler input modules,
especially the
request module, the request attribute module and the flow attribute
module, makes it possible to have a *cleaner* SOC, than it is
possible
Bruno Dumon bruno at outerthought.org writes:
Problem: readFromRequest() causes validation on all widgets in their order in
the form definition.
Which version are you using? I thought Sylvain fixed this a couple of
days ago.
Only the latest release 2.1.4. You mean the early validation on
Christopher Oliver wrote:
Reinhard Poetz wrote:
snip
I already said in several mails that we should reduce the recommended
options:
1.) Use O/R-mapper if possible
2.) if you only have publishing tasks use the sqlTransformer
3.) If the learning curve for an O/R-mapper is too steep for you take
I change my non-binding vote to -1.
Motivation:
When you have a block of code that uses other modules, you often end up
doing:
try {
...
} catch (Exception e) {
// Whatever the cause, it didn't work.
throw new MyException (e);
}
Since RuntimeException isa
Leon Widdershoven wrote:
I honestly do not care about the efficiency of my SQL. The database is
by far the fastest component. I do not think OJB can really optimize
a simple SELECT foo, bar from BLA; statement. There's just nothing to
optimize!
You can always optimize it away. That is, don't do
Ugo Cei wrote:
Leon Widdershoven wrote:
I honestly do not care about the efficiency of my SQL. The database is
by far the fastest component. I do not think OJB can really optimize
a simple SELECT foo, bar from BLA; statement. There's just nothing to
optimize!
You can always optimize it away.
Christopher Oliver wrote:
Reinhard Poetz wrote:
snip
I already said in several mails that we should reduce the recommended
options:
1.) Use O/R-mapper if possible
2.) if you only have publishing tasks use the sqlTransformer
3.) If the learning curve for an O/R-mapper is too steep for you take
Leo Sutic wrote:
I change my non-binding vote to -1.
Motivation:
When you have a block of code that uses other modules, you often end up
doing:
try {
...
} catch (Exception e) {
// Whatever the cause, it didn't work.
throw new MyException (e);
}
Since
From: Ugo Cei [mailto:[EMAIL PROTECTED]
Therefore, ProcessingException should really be ProcessingError -
since you're not expected to recover from it. Or extend Throwable
directly.
Well that's more radical than my proposal! You won't catch it even if
you do catch(Exception e).
Joerg Heinicke wrote:
IMO it's only important to separate code changes clearly from style
changes.
+1
Vadim
Joerg Heinicke wrote:
On 19.04.2004 22:36, Ugo Cei wrote:
Il giorno 19/apr/04, alle 20:43, Joerg Heinicke ha scritto:
Joerg -1
Should we interpret this as a veto?
Ah, no, I do not see myself that important :) Just another -1.
Add another -1 from me. I'm with Nicola here, it
Hi,ugo:
I checked CalendarGenerator today and thought about how it can be used.I was a Lotus
Notes programmer,there's a kind of calendar view in Notes.We like to display
meetings,arrangements(scheduling stuffs) in this kind of view.Today I check
http://localhost:/samples/cal ,it looks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28495.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Carsten Ziegeler wrote:
Marc Portier wrote:
in general I'm all for a more formal description of the
meaning of versions to us.
something like: http://apr.apache.org/versioning.html but
probably more focussed towards Java classes, interfaces, xml
schema's and namespaces ?
from there we
roy huang wrote:
Hi,ugo:
I checked CalendarGenerator today and thought about how it can be used.I was a
Lotus Notes programmer,there's a kind of calendar view in Notes.We like to display
meetings,arrangements(scheduling stuffs) in this kind of view.Today I check
I've posted this as bug #28495.
In org.apache.cocoon.acting.modular.DatabaseAction, the implemented query
caching is inoperative.
In the processTable() method a new LookUpKey is created for every request,
and since the equals/hashKey methods are not overriden in LookUpKey, this
means that the
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
snip /
IMO we can move on with 2.1.x and remove the depracated
classes if this is necessary. WDYT?
To be honest, this was my first thinking as well :) But there is
the general perception that a minor version change is 100%
compatible (or 99.9%)
Carsten Ziegeler wrote:
Joerg Heinicke wrote:
snip /
Now the confusion starts. IMO we should have clear
version/repository matchings.
Yes, a clear matching is required. We would have the clear matching
of Any cocoon version = 2.1 is in the cocoon-2.1 repository :)
LOL.
Of course, if we
Marc Portier wrote:
Hm, I think I'm swinging towards the observations you made in
opening this thread.
We seem to have grown some implicit meaning (expectations)
around these version numbers, I don't think we should ignore that...
I'm not the kind of guy that wants everything
Hi,Ugo
I will try to write some code to solve my need before may,but it may not as good
as yours.I will send the code to you after my work.
Roy Huang
- Original Message -
From: Ugo Cei [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 9:18 PM
Subject: Re:
Marc Portier wrote:
here goes:
I see some difference between what I would call 'extension'
vs. 'usage'
compatibility
snip explains/
I like the distinction and I totally agree with the vision of
'usage'. In my RT about versions I was only refering to
the 'extension' are when it comes to
Hi,
I need an orb connection using OpenORB. Using Tomcat I simply added the
appropriate jars to the lib and
-Dopenorb.home=path/to/config
to the catalina.bat file and it works.
Now I want to reproduce this using Jetty, since this makes it easier to test
my webapp, but I cannot get it up and
On Apr 19, 2004, at 4:49 PM, Reinhard Poetz wrote:
leo leonid wrote:
Hi all,
just curious, did ever someone in cocoonland, except me, use the
SQL-Maps and DAO-Framework from ibatis ( www.ibatis.com ). This is
from where Chris borrowed the Petstore sample, that he ported to
flow. And that was
Ugo Cei wrote:
Il giorno 19/apr/04, alle 20:43, Joerg Heinicke ha scritto:
Joerg -1
Should we interpret this as a veto?
It's not up to interpretation, as nobody can veto [VOTE]s.
Vetos can only be used to revert commits that should not happen because
of problems they generate, and be
First, I love the link that Marc posted. That is exactly what Cocoon needs
- a page on the web site stating what contract the Cocoon project has with
its users. It doesn't matter too much what that contract is, as long as it
is followed and provides a reasonable level of support.
In discussing
Me and Jerm (who's working right beside me ATM) have found some
problems with the serializers shipped with XALAN, as outlined in those
messages that randomly hit the mailing list...
I basically fixed the GARBAGE serializers to work now cleanly as cocoon
serializers, simple job, but as far as
On 20 Apr 2004, at 15:41, Pier Fumagalli wrote:
Me and Jerm (who's working right beside me ATM) have found some
problems with the serializers shipped with XALAN, as outlined in those
messages that randomly hit the mailing list...
I basically fixed the GARBAGE serializers to work now cleanly as
Nicola Ken Barozzi wrote:
Should we interpret this as a veto?
It's not up to interpretation, as nobody can veto [VOTE]s.
Vetos can only be used to revert commits that should not happen because
of problems they generate, and be accompanied with solid technical reasons.
Thank you for the
Carsten Ziegeler wrote:
Ok,
I have counted +1 from Stefano, Antonio, Reinhard, Ralph and
Gianugo (and myself of course :) )
+1
I'm behind on my mail a bit...
Vadim
Hi!
I'm currently trying to use the xmldb source. However I've spotted a
problem. The source doesn't currently handle xpaths with namespaces.
We have a few suggestions for how to make it do this:
(i) Turn the source path into pure Xpointer commands e.g.:
Hi Pier --
Pier Fumagalli wrote:
I basically fixed the GARBAGE serializers to work now cleanly as cocoon
serializers, simple job, but as far as we could see, the new ones work
much _MUCH_ better than Xalan's own (they might be slower, but they're
more compliant).
I've been using your
From Jetbrains homepage (the creators of Intellij IDEA):
Fabrique is a Rapid Application Development environment for developing
sophisticated web and enterprise applications.
http://www.jetbrains.com/fabrique/
This hasnt really that much to do with Cocoon but one can dream about a
similar IDE
On 20 Apr 2004, at 16:12, Steve Krulewitz wrote:
Hi Pier --
Pier Fumagalli wrote:
I basically fixed the GARBAGE serializers to work now cleanly as
cocoon serializers, simple job, but as far as we could see, the new
ones work much _MUCH_ better than Xalan's own (they might be slower,
but
Yes, resurfacing a topic from last year,
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105231353428562w=2
.. a change I voted -1 on at the time, no less!
He's my current situation, and afaik, a redirect in handle-errors is
what I need, but I may be wrong.
For a particular segment of my
peter royal wrote:
Yes, resurfacing a topic from last year,
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105231353428562w=2
.. a change I voted -1 on at the time, no less!
He's my current situation, and afaik, a redirect in handle-errors is
what I need, but I may be wrong.
For a particular
Nicola Ken Barozzi wrote:
Ugo Cei wrote:
Nicola Ken Barozzi wrote:
Should we interpret this as a veto?
It's not up to interpretation, as nobody can veto [VOTE]s.
Vetos can only be used to revert commits that should not happen
because of problems they generate, and be accompanied with solid
On Apr 20, 2004, at 12:22 PM, Tony Collen wrote:
If a URL with an invalid continuation ID is invoked, I would like to
take the user to the start of the process rather than displaying an
error page. AFAIK, this needs a redirect-to in the handle-errors
block. I can think of several ways of
We've run into a situation using Cocoon 2.1.4, where under load, sometimes we
seem to get wires crossed and sax event streams get mixed up between
different user sessions.
Or it might be some other weird concurrency bug elsewhere.
Any known bugs/fixes in this area?
Thanks!
Andrzej Jan
Ugo Cei wrote:
Nicola Ken Barozzi wrote:
Ugo Cei wrote:
Nicola Ken Barozzi wrote:
Should we interpret this as a veto?
It's not up to interpretation, as nobody can veto [VOTE]s.
Vetos can only be used to revert commits that should not happen
because of problems they generate, and be
I don't believe all apache projects are required to follow those voting
procedures. However, I can't think of a good reason why not to. If someone
is trusted enough to be a committer I would hope they would have the common
sense to use their veto power judiciously.
Ralph
-Original
Il giorno 20/apr/04, alle 18:55, Nicola Ken Barozzi ha scritto:
These rules are the ones that came out of HTTPD land, and reflect a
codebase that changes very differently from ours. What you should
really be looking at is: http://xml.apache.org/decisions.html
I had already looked there, but
These things were discussed to death at Avalon.
My personal guideline is this: If you have -1's you don't have
consensus.
Unless you have consensus, you shouldn't implement whatever
it is you propose.
As for the problem with someone being completely uncooperative,
well...
/LS
From: Ugo Cei
Ugo Cei wrote:
Il giorno 20/apr/04, alle 18:55, Nicola Ken Barozzi ha scritto:
These rules are the ones that came out of HTTPD land, and reflect a
codebase that changes very differently from ours. What you should
really be looking at is: http://xml.apache.org/decisions.html
I had already
Leon Widdershoven [EMAIL PROTECTED] writes:
snip/
I don't see much difference between marking something private vs.
not for normal access by end users? In fact I think the
RAD flag
would be a little more liberal than private vs. public since if you
needed you could always flag a
Il giorno 20/apr/04, alle 19:52, Nicola Ken Barozzi ha scritto:
In any case, we need our guidelines.
+1 ;-).
Ugo
peter royal wrote:
i could also create a custom Action since that gets a handle to a
Redirector.
How about a redirecting seriliazer (possibly if certain conditions are
met in the SAX stream, e.g. xpath predicate)?
andy
--
[EMAIL PROTECTED] / [EMAIL PROTECTED]
Absinthe makes the hog Jane Fonda
Daniel Fagerstrom [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
snipexamples/snip
So, lets see, I started with a 7 line sitemap snippet, where
most Cocoon
users should be able to understand at a course level what is going on
after short look at it. Then I proposed that the
Antonio Gallardo wrote:
Tony Collen dijo:
Hmm, how hard would it be to come up with some sort of Avalon component
that wraps OJB's PersistenceManager? Or would we not even have to use
it as an Avalon component if we can just directly get a
PersistenceManager instance?
I would wager that if we
On 20.04.2004 16:41, Pier Fumagalli wrote:
Me and Jerm (who's working right beside me ATM) have found some problems
with the serializers shipped with XALAN, as outlined in those messages
that randomly hit the mailing list...
Did I miss them? Which messages and which problems? Why are the
Andrzej Jan Taramina wrote:
I've posted this as bug #28495.
In org.apache.cocoon.acting.modular.DatabaseAction, the implemented query
caching is inoperative.
In the processTable() method a new LookUpKey is created for every request,
and since the equals/hashKey methods are not overriden in
the only recent message that sounds vaguely familiar is this:
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=108154185315695w=2
would be nice if you could use your setup to gather some more info on
the issue
-marc=
Andrzej Jan Taramina wrote:
We've run into a situation using Cocoon 2.1.4,
Andrew Thornton wrote:
Hi!
I'm currently trying to use the xmldb source. However I've spotted
a problem. The source doesn't currently handle xpaths with namespaces.
We have a few suggestions for how to make it do this:
...
Il giorno 20/apr/04, alle 19:40, Leo Sutic ha scritto:
My personal guideline is this: If you have -1's you don't have
consensus.
Unless you have consensus, you shouldn't implement whatever
it is you propose.
I'm inclined to refrain from making this change now. The vote is more
or less split,
Ugo Cei wrote:
roy huang wrote:
Hi,ugo:
I checked CalendarGenerator today and thought about how it can be used.I was a Lotus
Notes programmer,there's a kind of calendar view in Notes.We like to display
meetings,arrangements(scheduling stuffs) in this kind of view.Today I check
On 20 Apr 2004, at 19:47, Joerg Heinicke wrote:
On 20.04.2004 16:41, Pier Fumagalli wrote:
Me and Jerm (who's working right beside me ATM) have found some
problems with the serializers shipped with XALAN, as outlined in
those messages that randomly hit the mailing list...
Did I miss them?
I'm a bit confused about the naming of version number parts.
I always thought, that version numbers are constructed like this:
MAJOR.MINOR.PATCH
I did some quick google search and found the following pages which seem
to confirm that:
http://apr.apache.org/versioning.html#strategy
Guido Casper wrote:
Leon Widdershoven wrote:
Guido Casper wrote:
Yes that might be one reason. Another one IMO is that it's much easier
to (conceptually) come up with a reusable sitemap component (being a
specialized thing) than it is to come up with a reusable flow
component.
Guido
I think
Guido Casper dijo:
That's interesting. Would you care to explain to me what the difference
between a DB transaction and an object transaction is?
In short:
Any O/R map tool has the DB model loaded in a set of diferent Java
Objects. That way, we have to worlds that need to be synchronized: The
[EMAIL PROTECTED] wrote:
mpo 2004/04/20 15:19:27
Modified:src/blocks/forms/java/org/apache/cocoon/forms/formmodel
Struct.java Messages.java Repeater.java
MultiValueField.java AbstractContainerWidget.java
Guido Casper dijo:
Yep. We can get OJB components outside Avalon. We are doing this too
now.
The remain question is to delete the OJB block or let it live to show
users how they can use it.
+1 to let it live as a lightweight block. If O/R-mapping is our
recommendation for enterprise level
On Wed, Apr 21, 2004 at 12:29:26AM +0200, Marc Portier wrote:
[EMAIL PROTECTED] wrote:
1/ should getWidget(id) be removed from Widget? It is already on
ContainerWidget (which is the true context that makes sense IMHO)
+1 remove it. It is historical from before we had the Container* code.
84 matches
Mail list logo
