Re: [proposal] Cleaning up our component library
Geoff Howard wrote: Reinhard Poetz wrote: From: Sylvain Wallez [mailto:[EMAIL PROTECTED] The source-copy action already exists in o.a.c.acting.CopySourceAction, and the o.a.c.c.flow.util.PipelineUtil class could easily be generalized to any source, and not only "cocoon:". Thanks for your answer and confirming that this would be a good idea. I don't have a use case yet (was just a thought I had when I read it) but if I have I'll implement it ;-) I implemented a first draft of something like this a month or so ago just for "fun" but may have lost it in a computer switch. I'll look for it and post/commit whatever I can find. Can't find what I was thinking of, so never mind... Geoff
Re: [proposal] Cleaning up our component library
Reinhard Poetz wrote: From: Sylvain Wallez [mailto:[EMAIL PROTECTED] The source-copy action already exists in o.a.c.acting.CopySourceAction, and the o.a.c.c.flow.util.PipelineUtil class could easily be generalized to any source, and not only "cocoon:". Thanks for your answer and confirming that this would be a good idea. I don't have a use case yet (was just a thought I had when I read it) but if I have I'll implement it ;-) I implemented a first draft of something like this a month or so ago just for "fun" but may have lost it in a computer switch. I'll look for it and post/commit whatever I can find. Geoff
RE: [proposal] Cleaning up our component library
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED] > The source-copy action already exists in > o.a.c.acting.CopySourceAction, > and the o.a.c.c.flow.util.PipelineUtil class could easily be > generalized > to any source, and not only "cocoon:". Thanks for your answer and confirming that this would be a good idea. I don't have a use case yet (was just a thought I had when I read it) but if I have I'll implement it ;-) -- Reinhard
Re: [proposal] Cleaning up our component library
Reinhard Poetz wrote:
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 28, 2004 6:13 PM
To: [EMAIL PROTECTED]
Subject: Re: [proposal] Cleaning up our component library
Ralph Goers wrote:
I thought actions were performed before generators and transformers?
If so, how could an action copy data from a generator or transformer?
Wouldn't a source-copy function a nice addition for FOM?
The source-copy action already exists in o.a.c.acting.CopySourceAction,
and the o.a.c.c.flow.util.PipelineUtil class could easily be generalized
to any source, and not only "cocoon:".
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
Re: [proposal] Cleaning up our component library
On 28.01.2004 16:44, Geoff Howard wrote: So alltogether: a) Components that are just renamed or replaced with only sitemap changes (FileGenerator => XMLGenerator, DirectoryGenerator => TraversableGenerator (or however it is called ;-) ), StreamGenerator => XMLGenerator + ModuleSource) are deprecated in 2.1 and removed in 2.2. b) Components that need "real" application changes as processPipelineTo or anything similar are also deprecated in 2.1, but will be kept in 2.2. c) Deprecation messages: Strict deprecation for a) components. 80% are catched by "file" => "xml" and "file" is the default generator and "xml" will be it. Loose deprecation with a warning on every usage (otherwise they are to easily lost in the logs) for b) components. If we also use strict deprecation here, we don't really need b). Some general notes: I think whatever we do in this area, we should make a vote for each change. Totally agree. Please do not make such changes without voting first on each change. Hey, of course! I never had in mind to "just change it". For example, I already have objectsion against renaming File / Directory Generators - those are the most intuitive / easy-to-use components we have today. File and Directory abstractions are well known throughout the computing world (including non-English speakers); and File / Directory does not have to be on the file system, they could be anywhere: WebDAV, XML:DB, etc. OTOH, TraversableGenerator is just *horrible* name. Ok, I can go with you with the DirectoryGenerator. The only problem here is that it is bound to the file system at the moment. We have the TraversableGenerator in our CVS, which is the more generic implementation, but with a bad name. We had already discussions on its name like HierarchyGenerator. I could also imagine to just replace the DirectoryGenerator with the TraversableGenerator and name the TG as DG. But it's another point with the FileGenerator. While the abstraction of file might be ok, you just can not read text or html files, but only XML. I am sort of one the fence here. I agree with the premise that our names are misleading in many cases. However, I think mass confusion may ensue if we rename mainstay components like the FileGenerator. Of course, we can move the real implementation to an XMLGenerator and make FileGenerator extend it, deprecating FileGenerator. That's a good compromise IMO. I wonder if we should move much more slowly on the removal end, focus on better naming conventions moving forward, and provide a very clear documentation explaining the paradox (e.g., "File" generator really works with any source which is already unparsed XML at its nature, if an appropriate Source exists to get at it). As people have been free to subclass any existing generator, I don't know how we can expect any real renaming to be "sitemap only". Subclassing is a good point. I only wonder if there is so much subclassed. Now, I say that mostly with the users list in mind and I defer to your (Joerg's) opinion greatly about that. (for devs unsubscribed on the users list, Joerg is absolutely indispensable there, IMO). Thanks. And we should only move things into the deprecated part if there is a usable alternative. IMHO, using flow instead of a transformer isn't really an alternative as the overhead is way to much (just my opinion here). -1 to replacing of SourceWritingTransformer with the flosw. It's name is a bit misleading, and SourceCopyAction sounds better to me, but any alternative to SWT must be non-flow. Ok, I see. Flow is not an option, but a component like the propagated action. And we should avoid the renaming trap - which means renaming things just because a "not so perfect" name has been chosen in the first place. IMHO there is no real use in this. But if the name is just wrong there is a real use. Also the renaming from File to XML would make it much more consistent as we have a HTMLGenerator, TextGenerator, MidiGenerator, JSPGenerator and so on. They all are files, but could not be read by FileGenerator. The core point of this generator is XML, not file. I sympathize with this too. The amount of documentation, (cvs, wiki, books, other external) that would become outdated scares me here. The naming is confusing, but not as confusing as inaccurate docs. What about doing "weak" deprecation, with good explanation that the move is in name only. INFO level logging on each use seems reasonable. But I'd propose that since this would come late in the 2.1 cycle that removing in 2.2 is too soon. I'd propose continue deprecation in 2.2 and remove only after that - maybe even a major version (i.e., 3.0). I understand your concerns about confusing users. But at the moment I see much more confusion for new users. Users that already know Cocoon and have to change their application because of my proposed changes know what they are doing, it's just a question of informing them appropriately.
RE: [proposal] Cleaning up our component library
> -Original Message-
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 28, 2004 6:13 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [proposal] Cleaning up our component library
>
>
> Ralph Goers wrote:
>
> >I thought actions were performed before generators and
> transformers?
> >If so, how could an action copy data from a generator or transformer?
> >
> >
>
> from="cocoon:/my-pipeline-with-generator-and-or-transformer-an
> d-whatever"
> to="xmldb:xindice:///db/orders/{order}"/>
Wouldn't a source-copy function a nice addition for FOM?
--
Reinhard
Re: [proposal] Cleaning up our component library
Le Mercredi, 28 jan 2004, à 11:52 Europe/Zurich, Joerg Heinicke a écrit : ...With our deprecated block we have another mean to lead the user to the new components. When it's excluded the application will just not work. But I don't know if this is true for 2.2 and real blocks too... hmm...I don't like the idea of moving code around to deprecate it, what if a block has just one component that must be deprecated? Also, with CVS we lose code history when moving files around. Marking components with a marker interface would be less disruptive and easier to undo if (when) mistakes happen. Then the component manager could trigger log messages or exceptions (depending on the "strict deprecation" setting) when initializing the component. So alltogether: a) Components that are just renamed or replaced with only sitemap changes (FileGenerator => XMLGenerator, DirectoryGenerator => TraversableGenerator (or however it is called ;-) ), StreamGenerator => XMLGenerator + ModuleSource) are deprecated in 2.1 and removed in 2.2 ok but I agree with Carsten that renaming just because names aren't optimal does not make much sense. b) Components that need "real" application changes as processPipelineTo or anything similar are also deprecated in 2.1, but will be kept in 2.2. ok c) Deprecation messages: Strict deprecation for a) components. 80% are catched by "file" => "xml" and "file" is the default generator and "xml" will be it. Loose deprecation with a warning on every usage (otherwise they are to easily lost in the logs) for b) components. If we also use strict deprecation here, we don't really need b). I was more thinking about a global "strict deprecation" setting, defaulting to false at first, but global. Either you leave it false to be able to use all components (with warnings) or you set it to true if you want to make sure your app doesn't use any deprecated stuff. -Bertrand
RE: [proposal] Cleaning up our component library
I'll admit that I didn't do the work evaluating Woody. My colleague indicated he had problems figuring out how to get Woody bindings to work without flow. If there are samples of that let me know and I'll have him look at it again. Thanks, Ralph -Original Message- From: Steven Noels [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 28, 2004 12:30 AM To: [EMAIL PROTECTED] Subject: Re: [proposal] Cleaning up our component library On Jan 28, 2004, at 8:43 AM, Ralph Goers wrote: > We'd love to use Woody (aka Cocoon Forms), but if it can be used > without > FlowScript it isn't obvious. Woody and FlowScript should be totally independent from each other. Much of the fun stuff lately has been done in the JS utility library, but Woody itself doesn't require FlowScript - there's examples of using Woody with Actions at http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/woody/java/org/ apache/cocoon/woody/acting/ and http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/woody/java/org/ apache/cocoon/woody/samples/
Re: [proposal] Cleaning up our component library
Ralph Goers wrote: I thought actions were performed before generators and transformers? If so, how could an action copy data from a generator or transformer? PS Fictious syntax used for simplicity Vadim
RE: [proposal] Cleaning up our component library
Joerg Heinicke <[EMAIL PROTECTED]> proposes: > I propose to > deprecate > those components in 2.1 and to remove them in 2.2. Yes please! As Cocoon grows it gets harder and harder to see the real direction it is heading as long as it continues to carry with it every single experiment and work around that no longer makes sense. Housecleaning is a good thing
RE: [proposal] Cleaning up our component library
I thought actions were performed before generators and transformers? If so, how could an action copy data from a generator or transformer? Ralph -Original Message- From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 28, 2004 8:11 AM To: [EMAIL PROTECTED] Subject: Re: [proposal] Cleaning up our component library I mean that there is already an action written to copy sources, if I'm not mistaken, which can copy one sosurce to another. Combined with cocoon protocol and all other protocols you can do a lot with it. But I'm not saying that I've analyzed all use cases and we should remove SWT. Some javadoc in SWT pointing to copy action (or other, more preferred, way) is the first step towards better use practices. Vadim
Re: [proposal] Cleaning up our component library
Geoff Howard wrote: Vadim Gritsenko wrote: And we should only move things into the deprecated part if there is a usable alternative. IMHO, using flow instead of a transformer isn't really an alternative as the overhead is way to much (just my opinion here). -1 to replacing of SourceWritingTransformer with the flosw. It's name is a bit misleading, and SourceCopyAction sounds better to me, but any alternative to SWT must be non-flow. You mean to change SWT to an Action? I mean that there is already an action written to copy sources, if I'm not mistaken, which can copy one sosurce to another. Combined with cocoon protocol and all other protocols you can do a lot with it. But I'm not saying that I've analyzed all use cases and we should remove SWT. Some javadoc in SWT pointing to copy action (or other, more preferred, way) is the first step towards better use practices. Vadim
RE: [proposal] Cleaning up our component library
I totally agree with this. I have focused totally on 2.1 in building our system. For things to suddenly be deprecated now would be most irritating. If 2.2 manages to make the process of building one's webapp easier with "real" blocks, a lot of folks like me will want to switch to it just for that. I really don't want to have to reimplement a bunch of stuff. -Original Message- From: Geoff Howard [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 28, 2004 7:45 AM To: [EMAIL PROTECTED] Subject: Re: [proposal] Cleaning up our component library What about doing "weak" deprecation, with good explanation that the move is in name only. INFO level logging on each use seems reasonable. But I'd propose that since this would come late in the 2.1 cycle that removing in 2.2 is too soon. I'd propose continue deprecation in 2.2 and remove only after that - maybe even a major version (i.e., 3.0). Geoff
RE: [proposal] Cleaning up our component library
From: Carsten Ziegeler > Joerg Heinicke wrote: > > So alltogether: > > > > a) Components that are just renamed or replaced with only sitemap > > changes (FileGenerator => XMLGenerator, DirectoryGenerator => > > TraversableGenerator (or however it is called ;-) ), > StreamGenerator => > > XMLGenerator + ModuleSource) are deprecated in 2.1 and > removed in 2.2. > > b) Components that need "real" application changes as > processPipelineTo > > or anything similar are also deprecated in 2.1, but will be > kept in 2.2. > > c) Deprecation messages: > > Strict deprecation for a) components. 80% are catched by > "file" => "xml" > > and "file" is the default generator and "xml" will be it. > > Loose deprecation with a warning on every usage (otherwise > they are to > > easily lost in the logs) for b) components. If we also use strict > > deprecation here, we don't really need b). > > > Some general notes: > > I think whatever we do in this area, we should make a vote > for each change. +1 > And we should only move things into the deprecated part if > there is a usable alternative. IMHO, using flow instead of a > transformer isn't really an alternative as the overhead is > way to much (just my opinion here). IIUC no flow but some input modules are the alternative here. > And we should avoid the renaming trap - which means renaming > things just because a "not so perfect" name has been chosen > in the first place. IMHO there is no real use in this. +1 -- Reinhard
Re: FW: [proposal] Cleaning up our component library
Bruno Dumon wrote: On Wed, 2004-01-28 at 08:43, Ralph Goers wrote: We'd love to use Woody (aka Cocoon Forms), but if it can be used without FlowScript it isn't obvious. So we will be using the SimpleFormTransformer etc., for the forseeable future. Woody doesn't require flowscript. While flowscript integration is available (and this way of working is most pushed for obvious reasons), the native API of Woody is still just a bunch of Java. The Woody samples show how to process a form from an Action, for example. Amen. I'd been using Woody with Action written in Java for some time. Worked well till I tired of modifying it too often to change flow. Vadim
Re: [proposal] Cleaning up our component library
Vadim Gritsenko wrote: Carsten Ziegeler wrote: Joerg Heinicke wrote: So alltogether: a) Components that are just renamed or replaced with only sitemap changes (FileGenerator => XMLGenerator, DirectoryGenerator => TraversableGenerator (or however it is called ;-) ), StreamGenerator => XMLGenerator + ModuleSource) are deprecated in 2.1 and removed in 2.2. b) Components that need "real" application changes as processPipelineTo or anything similar are also deprecated in 2.1, but will be kept in 2.2. c) Deprecation messages: Strict deprecation for a) components. 80% are catched by "file" => "xml" and "file" is the default generator and "xml" will be it. Loose deprecation with a warning on every usage (otherwise they are to easily lost in the logs) for b) components. If we also use strict deprecation here, we don't really need b). Some general notes: I think whatever we do in this area, we should make a vote for each change. Totally agree. Please do not make such changes without voting first on each change. For example, I already have objectsion against renaming File / Directory Generators - those are the most intuitive / easy-to-use components we have today. File and Directory abstractions are well known throughout the computing world (including non-English speakers); and File / Directory does not have to be on the file system, they could be anywhere: WebDAV, XML:DB, etc. OTOH, TraversableGenerator is just *horrible* name. I am sort of one the fence here. I agree with the premise that our names are misleading in many cases. However, I think mass confusion may ensue if we rename mainstay components like the FileGenerator. Of course, we can move the real implementation to an XMLGenerator and make FileGenerator extend it, deprecating FileGenerator. I wonder if we should move much more slowly on the removal end, focus on better naming conventions moving forward, and provide a very clear documentation explaining the paradox (e.g., "File" generator really works with any source which is already unparsed XML at its nature, if an appropriate Source exists to get at it). As people have been free to subclass any existing generator, I don't know how we can expect any real renaming to be "sitemap only". Now, I say that mostly with the users list in mind and I defer to your (Joerg's) opinion greatly about that. (for devs unsubscribed on the users list, Joerg is absolutely indispensable there, IMO). And we should only move things into the deprecated part if there is a usable alternative. IMHO, using flow instead of a transformer isn't really an alternative as the overhead is way to much (just my opinion here). -1 to replacing of SourceWritingTransformer with the flosw. It's name is a bit misleading, and SourceCopyAction sounds better to me, but any alternative to SWT must be non-flow. You mean to change SWT to an Action? And we should avoid the renaming trap - which means renaming things just because a "not so perfect" name has been chosen in the first place. IMHO there is no real use in this. Ditto. I sympathize with this too. The amount of documentation, (cvs, wiki, books, other external) that would become outdated scares me here. The naming is confusing, but not as confusing as inaccurate docs. What about doing "weak" deprecation, with good explanation that the move is in name only. INFO level logging on each use seems reasonable. But I'd propose that since this would come late in the 2.1 cycle that removing in 2.2 is too soon. I'd propose continue deprecation in 2.2 and remove only after that - maybe even a major version (i.e., 3.0). Geoff
RE: [proposal] Cleaning up our component library
Ralph Goers <[EMAIL PROTECTED]> writes: > Our > environment has special security concerns that just won't > allow a scripting language - or even JSPs or XSPs for that > matter. Ok, I'll bite; why single out scripting languages and dynamically produced pages? What about dynamically compiled Java? How about XSLts? It is just as easy to inject a security hole into a non-scripted language as a scripted one; perhaps easier since people rarely think to inspect the byte streams of the compiled code where as the source of the scripted language is all there is (assuming you trust the compilers and interpreters). Banning scripting on the client side I might understand. This however, seems like a very poorly thought out security policy; instead of determining what the real security exposures are a blanket decision was made to ban some very useful tools on the off chance they might be misused.
Re: [proposal] Cleaning up our component library
Carsten Ziegeler wrote: Joerg Heinicke wrote: So alltogether: a) Components that are just renamed or replaced with only sitemap changes (FileGenerator => XMLGenerator, DirectoryGenerator => TraversableGenerator (or however it is called ;-) ), StreamGenerator => XMLGenerator + ModuleSource) are deprecated in 2.1 and removed in 2.2. b) Components that need "real" application changes as processPipelineTo or anything similar are also deprecated in 2.1, but will be kept in 2.2. c) Deprecation messages: Strict deprecation for a) components. 80% are catched by "file" => "xml" and "file" is the default generator and "xml" will be it. Loose deprecation with a warning on every usage (otherwise they are to easily lost in the logs) for b) components. If we also use strict deprecation here, we don't really need b). Some general notes: I think whatever we do in this area, we should make a vote for each change. Totally agree. Please do not make such changes without voting first on each change. For example, I already have objectsion against renaming File / Directory Generators - those are the most intuitive / easy-to-use components we have today. File and Directory abstractions are well known throughout the computing world (including non-English speakers); and File / Directory does not have to be on the file system, they could be anywhere: WebDAV, XML:DB, etc. OTOH, TraversableGenerator is just *horrible* name. And we should only move things into the deprecated part if there is a usable alternative. IMHO, using flow instead of a transformer isn't really an alternative as the overhead is way to much (just my opinion here). -1 to replacing of SourceWritingTransformer with the flosw. It's name is a bit misleading, and SourceCopyAction sounds better to me, but any alternative to SWT must be non-flow. And we should avoid the renaming trap - which means renaming things just because a "not so perfect" name has been chosen in the first place. IMHO there is no real use in this. Ditto. Vadim
RE: [proposal] Cleaning up our component library
Joerg Heinicke wrote: > So alltogether: > > a) Components that are just renamed or replaced with only sitemap > changes (FileGenerator => XMLGenerator, DirectoryGenerator => > TraversableGenerator (or however it is called ;-) ), StreamGenerator => > XMLGenerator + ModuleSource) are deprecated in 2.1 and removed in 2.2. > b) Components that need "real" application changes as processPipelineTo > or anything similar are also deprecated in 2.1, but will be kept in 2.2. > c) Deprecation messages: > Strict deprecation for a) components. 80% are catched by "file" => "xml" > and "file" is the default generator and "xml" will be it. > Loose deprecation with a warning on every usage (otherwise they are to > easily lost in the logs) for b) components. If we also use strict > deprecation here, we don't really need b). > Some general notes: I think whatever we do in this area, we should make a vote for each change. And we should only move things into the deprecated part if there is a usable alternative. IMHO, using flow instead of a transformer isn't really an alternative as the overhead is way to much (just my opinion here). And we should avoid the renaming trap - which means renaming things just because a "not so perfect" name has been chosen in the first place. IMHO there is no real use in this. Carsten
RE: [proposal] Cleaning up our component library
From: Joerg Heinicke > One problem often mentioned is that Cocoon provides to many > possibilities to achieve some goals. Cocoon's flexibility > ends where it > is more confusing than helpful. Therefore I want to propose to > remove/deprecate the components that are no longer the correct way to > go, that are misleading by name or just don't do what their type of > component is intended to do. > > I already asked the question for replacement when Daniel > introduced the > (X)ModuleSource's. The StreamGenerator reads from the stream - but > that's not what the component generator is about. The > difference between > generators should not be the type of the sources, but the type of the > content. The same is true for the FileGenerator. For those I > propose a > simple XMLGenerator as we have a HTMLGenerator. The type of > the source > is given by the source, i.e. @src. Furthermore the name > FileGenerator is > misleading as it reads from http: or cocoon: or any other XML > source too. > > Another example or the "wrong" components as > [Read|Write]DOMSessionTransformer or > SourceWritingTransformer. They are > not transformers in the closer sense, they just tee the > pipeline. They > should be completely removed and replaced with either > XModuleSource and > aggregation (read) or FlowScript's processPipelineTo (write). > > Similar as for the FileGenerator the DirectoryGenerator is "out of > date", we already have the replacement in our CVS. > > I guess there are some more components that does not meet their > intention (seen from the component type's POV). I propose to > deprecate > those components in 2.1 and to remove them in 2.2. When the clear > separation of concerns is more obvious than now (generation, > aggregation, source, etc.) it will also be easier for the > Cocoon users > (especially new users) to dive into Cocoon and understand the > principles > of it. Therefore some backwards "incompatibilities" (it's not real > incompatibility, but some components in the sitemap must be replaced > when moving from 2.1 to 2.2) are the price to pay. I'm +1 to move the named components into the "deprecated" block because this perfectly signals your intentions and removing in 2.2 is okay for me because I think there will follow some more 2.1.x releases before we ship 2.2. -- Reinhard
Re: [proposal] Cleaning up our component library
On 28.01.2004 07:52, Bertrand Delacretaz wrote:
One problem often mentioned is that Cocoon provides to many
possibilities to achieve some goals. Cocoon's flexibility ends where
it is more confusing than helpful. Therefore I want to propose to
remove/deprecate the components that are no longer the correct way to
go, that are misleading by name or just don't do what their type of
component is intended to do
Sounds good, too many options do not help.
...Another example or the "wrong" components as
[Read|Write]DOMSessionTransformer or SourceWritingTransformer. They
are not transformers in the closer sense, they just tee the pipeline.
They should be completely removed and replaced with either
XModuleSource and aggregation (read) or FlowScript's processPipelineTo
(write)
Ok on the intention, but by removing these you force users to change
their code, not only replace some components in the sitemap as you
mention. I'm not sure about removing them unless they get in the way.
You are right. I did not have the "more than sitemap"-changes in mind
when thinking about the consequences.
How about:
a) components marked "deprecated" log a warning when used (or when used
for the first time)
b) maybe add an option to throw an exception when such components are
used ("strict deprecation")
c) deprecated components requiring code changes to user applications are
kept in 2.2, unless keeping them is too much work.
WDYT?
With our deprecated block we have another mean to lead the user to the
new components. When it's excluded the application will just not work.
But I don't know if this is true for 2.2 and real blocks too.
So alltogether:
a) Components that are just renamed or replaced with only sitemap
changes (FileGenerator => XMLGenerator, DirectoryGenerator =>
TraversableGenerator (or however it is called ;-) ), StreamGenerator =>
XMLGenerator + ModuleSource) are deprecated in 2.1 and removed in 2.2.
b) Components that need "real" application changes as processPipelineTo
or anything similar are also deprecated in 2.1, but will be kept in 2.2.
c) Deprecation messages:
Strict deprecation for a) components. 80% are catched by "file" => "xml"
and "file" is the default generator and "xml" will be it.
Loose deprecation with a warning on every usage (otherwise they are to
easily lost in the logs) for b) components. If we also use strict
deprecation here, we don't really need b).
Joerg
Re: [proposal] Cleaning up our component library
On 28.01.2004 10:55, Andreas Hartmann wrote:
b) maybe add an option to throw an exception when such components are
used ("strict deprecation")
This sounds very useful. There are some non-IDE users in
our community who aren't that much aware of deprecation.
Could it be switched on/off globally?
Might be doable through a build system property. Strict deprecation
would be on per default with a hint onto the property in the message, so
that they can make their applications run again.
Joerg
Re: [proposal] Cleaning up our component library
Bertrand Delacretaz wrote:
Le Mercredi, 28 jan 2004, à 02:40 Europe/Zurich, Joerg Heinicke a écrit :
[...]
...I propose to deprecate those components in 2.1 and to remove them
in 2.2...
In cases where this just needs sitemap changes, no problem. But if
deprecation requires code changes to existing applications we might want
to move in smaller steps.
How about:
a) components marked "deprecated" log a warning when used (or when used
for the first time)
For the Lenya community it would be very helpful if the number
of options was reduced (and I think this is also true for others).
I'm not a "real" Cocoon committer, but very +1 for marking
outdated components as deprecated.
b) maybe add an option to throw an exception when such components are
used ("strict deprecation")
This sounds very useful. There are some non-IDE users in
our community who aren't that much aware of deprecation.
Could it be switched on/off globally?
-- Andreas
Re: [proposal] Cleaning up our component library
On Jan 28, 2004, at 8:43 AM, Ralph Goers wrote: We'd love to use Woody (aka Cocoon Forms), but if it can be used without FlowScript it isn't obvious. Woody and FlowScript should be totally independent from each other. Much of the fun stuff lately has been done in the JS utility library, but Woody itself doesn't require FlowScript - there's examples of using Woody with Actions at http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/woody/java/org/ apache/cocoon/woody/acting/ and http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/woody/java/org/ apache/cocoon/woody/samples/ -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java & XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: FW: [proposal] Cleaning up our component library
On Wed, 2004-01-28 at 08:43, Ralph Goers wrote: > > We'd love to use Woody (aka Cocoon Forms), but if it can be used without > FlowScript it isn't obvious. So we will be using the > SimpleFormTransformer etc., for the forseeable future. Woody doesn't require flowscript. While flowscript integration is available (and this way of working is most pushed for obvious reasons), the native API of Woody is still just a bunch of Java. The Woody samples show how to process a form from an Action, for example. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [proposal] Cleaning up our component library
Le Mercredi, 28 jan 2004, à 02:40 Europe/Zurich, Joerg Heinicke a écrit
:
One problem often mentioned is that Cocoon provides to many
possibilities to achieve some goals. Cocoon's flexibility ends where
it is more confusing than helpful. Therefore I want to propose to
remove/deprecate the components that are no longer the correct way to
go, that are misleading by name or just don't do what their type of
component is intended to do
Sounds good, too many options do not help.
...Another example or the "wrong" components as
[Read|Write]DOMSessionTransformer or SourceWritingTransformer. They
are not transformers in the closer sense, they just tee the pipeline.
They should be completely removed and replaced with either
XModuleSource and aggregation (read) or FlowScript's processPipelineTo
(write)
Ok on the intention, but by removing these you force users to change
their code, not only replace some components in the sitemap as you
mention. I'm not sure about removing them unless they get in the way.
...I propose to deprecate those components in 2.1 and to remove them
in 2.2...
In cases where this just needs sitemap changes, no problem. But if
deprecation requires code changes to existing applications we might
want to move in smaller steps.
How about:
a) components marked "deprecated" log a warning when used (or when used
for the first time)
b) maybe add an option to throw an exception when such components are
used ("strict deprecation")
c) deprecated components requiring code changes to user applications
are kept in 2.2, unless keeping them is too much work.
WDYT?
-Bertrand
FW: [proposal] Cleaning up our component library
Darn. Meant for this to go to the list, not to you directly. -Original Message- From: Ralph Goers To: 'Joerg Heinicke ' Sent: 1/27/2004 9:06 PM Subject: RE: [proposal] Cleaning up our component library I realise I am fairly new to Cocoon and my opinion probably doesn't carry as much weight as most of yours. In many ways I agree with you, but not all. In particular, I am not in favor of removing components if their replacement requires flowscript. In my company we won't/can't use it. Our environment has special security concerns that just won't allow a scripting language - or even JSPs or XSPs for that matter. One of the things we love is that the flow can be completely implemented through the sitemap and a few custom compoents, as well as those already provided by Cocoon. We'd love to use Woody (aka Cocoon Forms), but if it can be used without FlowScript it isn't obvious. So we will be using the SimpleFormTransformer etc., for the forseeable future. One of the things I abhor about Java Open Source projects is their apparent disregard for backward compatibility. If any of you read the forum at theserverside.com about the release of Commons Collections 3.0 you will know what I am talking about. So while providing strong guidance on best practices is great, IMO removing classes that have been released should only be done after the classes have been deprecated for at least one release. Ralph -Original Message- From: Joerg Heinicke To: [EMAIL PROTECTED] Sent: 1/27/2004 5:40 PM Subject: [proposal] Cleaning up our component library Another example or the "wrong" components as [Read|Write]DOMSessionTransformer or SourceWritingTransformer. They are not transformers in the closer sense, they just tee the pipeline. They should be completely removed and replaced with either XModuleSource and aggregation (read) or FlowScript's processPipelineTo (write). Similar as for the FileGenerator the DirectoryGenerator is "out of date", we already have the replacement in our CVS. WDYT? Joerg
[proposal] Cleaning up our component library
One problem often mentioned is that Cocoon provides to many possibilities to achieve some goals. Cocoon's flexibility ends where it is more confusing than helpful. Therefore I want to propose to remove/deprecate the components that are no longer the correct way to go, that are misleading by name or just don't do what their type of component is intended to do. I already asked the question for replacement when Daniel introduced the (X)ModuleSource's. The StreamGenerator reads from the stream - but that's not what the component generator is about. The difference between generators should not be the type of the sources, but the type of the content. The same is true for the FileGenerator. For those I propose a simple XMLGenerator as we have a HTMLGenerator. The type of the source is given by the source, i.e. @src. Furthermore the name FileGenerator is misleading as it reads from http: or cocoon: or any other XML source too. Another example or the "wrong" components as [Read|Write]DOMSessionTransformer or SourceWritingTransformer. They are not transformers in the closer sense, they just tee the pipeline. They should be completely removed and replaced with either XModuleSource and aggregation (read) or FlowScript's processPipelineTo (write). Similar as for the FileGenerator the DirectoryGenerator is "out of date", we already have the replacement in our CVS. I guess there are some more components that does not meet their intention (seen from the component type's POV). I propose to deprecate those components in 2.1 and to remove them in 2.2. When the clear separation of concerns is more obvious than now (generation, aggregation, source, etc.) it will also be easier for the Cocoon users (especially new users) to dive into Cocoon and understand the principles of it. Therefore some backwards "incompatibilities" (it's not real incompatibility, but some components in the sitemap must be replaced when moving from 2.1 to 2.2) are the price to pay. WDYT? Joerg
