Stefano Mazzocchi wrote:
I don't feel attacked, Stefano, you are always very friendly; I'm just trying to tell you that it would be easier and more productive for /me/ if you could help me with actual examples. I should/will do it too, and I cannot really ask you to do it, since you are giving your free time like me...Nicola Ken Barozzi wrote:Stefano Mazzocchi wrote:Nicola Ken Barozzi wrote:Upayavira wrote:Dear All,
I have got a prototype CocoonBean that I would like to make available. A few questions:
1) I have used my own package names, but would like to use org.apache.cocoon ones. What is the process for deciding these?
decide them yourself, as they seem more appropriate.
When we will commit the patch, we could change them for consistency sake. I cannot help you more without seeing the code.
Agreed.Suggestion: org.apache.cocoon.environment.beanWhy? I don't see a cocoon bean as part of the environment.
Stefano, please excuse me, but you keep asking questions and I don't see many concrete examples from you (either). It's difficult for me to keep track of all the discussions and reply to all your questions. Please help me find solutions and counterproposals. My energy is not infinite, please help me.
I apologize if you felt attacked, my friend, it was not my intention.
[...]
Please, never forget that I would not spending time replying to a message if I didn't consider it valuable and I didn't appreciate your effort in writing it.I know, sorry if seemed to feel pissed off. I wasn't, I just feel sometimes I'm alone in pushing concretely forward in these discussions. Sorry.
ReLook at how o.a.c.Cocoon is setup and used in Main.java, and you'll see how nobody would use it in its code, it's way too complicated.I could ask you, then what do you think a cocoon bean would look like?
the o.a.c.Cocoon class is what I already consider as a bean (or a processor for that matter).. in fact, it was designed to be an Avalon Block (and could easily become one)... at the same time, my vision is limited and I wanted to see other visions and talk about them, that's why I asked since you seemed to have a more precise vision.
We had already talked a bit about this, and we thought that maybe making a second CocoonBean class would be better with regards to compatibility with old code that relies on Cocoon.java, but actually I would prefer Cocoon.java to be that bean/service.
Ok, I've seen it now and it's interesting.This is my simplified view:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/morphos/src/java/org/apache/commons/morphos/Morpher.java?rev=HEAD&content-type=text/vnd.viewcvs-markup
In essence (with the due changes):
void setInput(Object input);
void setOutput(Object output);
void morph() throws MorphException;
How do I set input... etc etc etc
So Upayavira, forget the suggestion and send the code.
Let's see what you have done.
Yep.
From what I've quickly seen, it still depends on the filesavingenvironment, and does not have a signature like the above example.
Good work, Upayavira, I'll take a deeper look at it now.
Thanks!
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
