On Fri, 25 Jul 2003 14:01:48 +0200, "Marc Portier" <[EMAIL PROTECTED]>
said:
<snip/>
> well, the current two ways I envisioned for the ant-task to know
> about the xconf are as follows:
>
> 1/
> <cocoonBean in="location-of-xconf" />
>
> 2/
> <cocoonBean>
> <xml-conf>
> INLINE XML OF THE XCONF FILE THAT CAN DO
> ${ant-props} SUBSTITUTION
> </xml-conf>
> </cocoonBean>
Definitely the latter would be best.
> in the first case the ant-task would know about the java.io.File
> in the second case the ant-task would probably have a
> String(Buffer) that holds the nested xconf data
>
> in both cases the task could present that as a InputStream
> (FileINputStrea, or StringBufferInputStream) to the processXConf
> method.
>
> in fact... typing this reply makes me think that the ant task
> could very well just have access to the xconf information as an
> already parsed DOM document in the second case... (as said before
> this second case is still very vague in my head ATM)
Can you explain how I would get hold of the contents of the <cocoonBean>
element as a DOM document from within the ant task code? That is _all_ I
need to get this working, AFAICS.
(Actually, I'd call the node <cocoon> as the fact that it is a bean is an
implementation fact. The user just wants to run Cocoon.)
> > Yes. So line.getArgList() is simply a list of requested Cocoon URIs.
> >
>
> ah, and that is not information that is present in the
> xconf file I persume?
It is present in the xconf, and in a much more sophisticated way. Look at
the cli.xconf file in the root of the Cocoon CVS. It is well commented.
Check specifically the <uris> node.
> >>my point is that each feature you add to the xconf (by changing
> >>bean and processXConf) should automatically be available to the
> >>ant-task (it should just pass through the xconf, not try to
> >>understand any of it IMHO)
> >
> > I would by far prefer to do it that way if we can find a way.
>
> I think we're close
> My basic proposition is this: the more we can put into the xconf
> (without breaking its common sense role) the easier the ant task
> will adapt to new features (cause it would only need to know
> about the fact that such file is to be handed over in some way or
> another)
Yup. Exactly what I have in mind. Just show me the DOM code :-)
> >>this will also make sure that people will only need to do one
> >>thing: understand how to write cocoon-bean xconf (not a different
> >>knowledge to configure the ant-task)
> >
> > That'd be great. At the moment, the xconf is a CLI xconf. Someone said
> > that it shouldn't be a part of the bean itself. But we can make it a
> > helper class, or a factory, that takes in configuration options and
> > returns a configured bean.
>
> there was some confusion over here as well about this self
> management, but I consider it a different issue (and I haven't
> looked enough into it)
I'll make a choice and let people complain.
> >>> cocoon.initialize();
> >>> cocoon.process();
> >>> cocoon.dispose();
> >>>
> >>> listener.outputBrokenLinks();
> >>
> >>ah, starting to understand why this is for...
> >>this could opt for an additional configuration element on the ant
> >>task: location where to dump this
> >
> > It is already specified in the cli.xconf, so it could be specified in the
> > ant task.
>
> well, my point was in fact: do not duplicate a thing that already
> is specified in the xconf.
No, no! It is already in the xconf, and would therefore already be in the
Ant task!
No work required!
> so if the output-location can be specified in the xconf, then I
> don't see a reason why the ant-task should try to duplicate that
> effort
>
> >>>BeanListener implementation (simply to decide what to do with output).
> >>
> >>got that now I think, again I hope for re-use: if I could
> >>instantiate such listener and call outputBrokenLinks() with the
> >>outputstream it needs to send to then your main could call it
> >>with System.out or whatever as an argument, and we'ld all be
> >>happy :-)
> >
> > Fair enough.
> >
>
> see above: no need for any of this if it can be dumped into the
> cli.xconf
>
> (I didn't realize the listener could be aware of specifics buried
> in the cli.xconf)
Well. At present, the Main.java class reads the xconf and configures the
bean or the listener. The ant task would do the same (using shared helper
classes).
...
> sure enough, the forrest community would get their hands on it
> pretty fast aswell IMHO
Great.
> (be sure to get them into the loop again when your getting somewhere)
Will do.
So, let me know how to access the contents of a task node as a DOM node,
and you'll (in time) get your Ant task.
How's that for a deal?
Regards, Upayavira
