Re: [RT] The impact of using OSGi

[Niclas Hedhman]

On Thursday 11 August 2005 06:34, Vadim Gritsenko wrote:
> Isn't it the first goal to make (any) existing block (with no code
> modifications) run under OSGi?

AFAIU, Existing blocks would run unchanged in the ECM<->OSGi bridge bundle.

I think Daniel is talking "real blocks" here, and I think that would require 
the blocks to have OSGi code in them, at least for the Bundle Activator and 
ServiceFactory. Of course there is an option to make a Cocoon specific 
abstraction level on top of the basic OSGi mechanisms, but to me it seems to 
only hamper the progress, resulting in endless debates of what to expose and 
not.

Put the stick in the ground. Declare "OSGi bundles is the plugin mechanism for 
Cocoon." Then move from there. :o)

Cheers
Niclas

Re: [cforms] fi:validation-errors in AJAX mode

[Jason Johnston]

Sylvain Wallez wrote:

Jason Johnston wrote:


Sylvain Wallez wrote:


Jason Johnston wrote:


On Mon, 2005-08-01 at 16:38 +0200, Sylvain Wallez wrote:
I think there's a definite usefulness in having it
AJAX-enabled, so perhaps it needs to be handled further upstream, e.g.
in FormsTemplateTransformer.  Should it become an ft-namespaced element
instead like ?  Thoughts?  I'm
willing to take a whack at putting together a patch, with guidance.
 


AFAIU its purpose, that would be a widget that collects validation 
errors from a set of other widgets. Its validate() method would check 
the if the collected validation errors have changed, and if yes 
trigger the page refresh.



So you're suggesting to actually make it a widget, as in 
fd:validation-errors, rather than just a template element?  That's an 
interesting idea... I think I'd rather keep it limited to the 
templating layer though, since it's really a presentation concern.



Ok. Tell us about your progress!



Just a little status update for y'all.

I've got a local patch working very nicely, and have a good start on 
filling some other holes in the AJAX support such as ft:widget-label.


However... I'm having to sit on these patches for the time being as I 
work through issues with my employer.  They currently have no OSS 
contribution policy to speak of, and are pretty anal when it comes to IP 
ownership, patents, etc. (bless the USA! :-\)  I'm confident I'll get 
clearance, as there's no benefit to the company to deny it, but 
unfortunately it's going to be on the committee's schedule.


Rest assured the patches will be submitted as soon as I get the 
go-ahead.  In the meantime if anyone else wants to tackle it on their 
own then they shouldn't be afraid to do so.


--Jason

Re: Architectural concerns

[Vadim Gritsenko]

Joerg Heinicke wrote:

On 10.08.2005 11:18, Kees Broenink wrote:


Suppose the data of the client does not have XML but only request
parameters. Now map this to Cocoon:
- generator that builds the SQL query using request parameters
- SQL transformer (adjusted to throw an exception on error)
- XSLT that creates a new piece of HTML unrelated to the previous
transformer (template match='/') - serialize

Now to me the first generator is already a farce. I made an SQL
transformer that simply accepts the query as parameter in stead of using
the XML stream.


You should not be using SQLTransformer at all - please take a look at Flow and 
ORM tools as others pointed out already.




Now if you look at this pattern from a higher
perspective you want to code this as follows:

- SQL transformer
- XML generator (no need to use an XSLT file)
- serialize



This shows exactly that the SQLTransformer is "problematic" or in other 
words "not best practice". Try to map Cocoon to a MVC scenario and you 
see that you should first build your model and retrieve it in a 
generator. The SQLTransformer breaks this concept.


There are perfectly valid scenarios where SQLTransformer is best tool for the 
job, and attemps to use 'model' layer fail (well, unless you consider ResultSet 
as a model ;-)). Streaming down large amount of data from the database 
(especially exceeding available memory) is one of them. In this case, it's 
impossible to process all database results in the model tier and pass it on to 
the view tier.


OTOH, trying to do application business logic using SQLTransformer is 
anti-pattern, and that's where you must go for MVC architecture.



But IMO it is not 
showing that Cocoon's pipeline concept as it is now has limitations. 
Jens already pointed to flow, that makes it easier to see Cocoon as 
player in a MVC concept.


Yep.





2. selectors are evaluated before the pipeline is executed

This basically means you can select on global, request and session
fields because these are already set. But of course you also want to
react on XML values in the stream. That is what you expect from an XML
pipeline architecture.
In short: I want to be able to choose different transformers depending
on the elements/attributes placed in the stream by the previous
transformer.


Forget it - this is another huge anti-pattern.


Besides the streaming mentioned by Torsten: This is even worse than the 
proposed TraxSerializer, the pipeline would be not predictable at all. 
And from the point that even biggest systems work quite well with Cocoon 
it's probably only FS.
(These systems might work (and be maintainable) only because Cocoon 
pipelines are based on clean and simple concepts ;-) )


Yep.

Vadim

Re: [RT] The impact of using OSGi

[Vadim Gritsenko]

Daniel Fagerstrom wrote:

Vadim Gritsenko wrote:

I'd even say that at this point in time, none of the existing blocks 
should be aware of OSGi existence but only Cocoon "Kernel", which uses 
OSGi to manage (load/unload) blocks on the fly.


Why?

Do you have any specific design for achieving this that you are going to 
propose?


May be I skipped important message - is there any reason why block's classes has 
to import OSGi?


Isn't it the first goal to make (any) existing block (with no code 
modifications) run under OSGi?



People, at this point of time it seem rather pointless to me to impose 
all sorts of restrictions on how we should implement blocks. Instead of 
discussing about how to not implement blocks I would prefer to focus on 
discussing how to implement them or even actually continue implementing 
them ;)


Sorry, had no time to look at it :-(

I noticed though that currently there is no 'CocoonServler' which would 
bootstrap OSGi container, isn't it?


Vadim

Re: Architectural concerns

[Joerg Heinicke]

On 10.08.2005 11:18, Kees Broenink wrote:


Suppose the data of the client does not have XML but only request
parameters. Now map this to Cocoon:
- generator that builds the SQL query using request parameters
- SQL transformer (adjusted to throw an exception on error)
- XSLT that creates a new piece of HTML unrelated to the previous
transformer (template match='/') 
- serialize


Now to me the first generator is already a farce. I made an SQL
transformer that simply accepts the query as parameter in stead of using
the XML stream. Now if you look at this pattern from a higher
perspective you want to code this as follows:

- SQL transformer
- XML generator (no need to use an XSLT file)
- serialize


This shows exactly that the SQLTransformer is "problematic" or in other 
words "not best practice". Try to map Cocoon to a MVC scenario and you 
see that you should first build your model and retrieve it in a 
generator. The SQLTransformer breaks this concept. But IMO it is not 
showing that Cocoon's pipeline concept as it is now has limitations. 
Jens already pointed to flow, that makes it easier to see Cocoon as 
player in a MVC concept.



Related to this issue is the Cocoon Aggregate statement.


...


If the Aggregate concept was mapped to the Transformer concept, it
could work.



People solve these limitations by using multiple pipelines, most of the
time with xinclude of cinclude. In that case the transformer basically
becomes a generator. It is clear that this is a workaround.


I don't agree with you. It's neither a generator nor a workaround. IMO 
the concept of an aggregating aka including transformer id really clear. 
The cleanness or "rigid implementation" is the most simple concept and 
allows highest reuse.



Also note that you will loose the {0}, {1} values of the orignal URI
when you call another pipeline.


On the one hand you can pass them (which is more effort than just having 
them of course), on the other hand you need more than just these 
placeholders.



2. selectors are evaluated before the pipeline is executed

This basically means you can select on global, request and session
fields because these are already set. But of course you also want to
react on XML values in the stream. That is what you expect from an XML
pipeline architecture.
In short: I want to be able to choose different transformers depending
on the elements/attributes placed in the stream by the previous
transformer.


Besides the streaming mentioned by Torsten: This is even worse than the 
proposed TraxSerializer, the pipeline would be not predictable at all. 
And from the point that even biggest systems work quite well with Cocoon 
it's probably only FS.
(These systems might work (and be maintainable) only because Cocoon 
pipelines are based on clean and simple concepts ;-) )


Joerg

Re: [RT] The impact of using OSGi

[Daniel Fagerstrom]

Vadim Gritsenko wrote:

Carsten Ziegeler wrote:


Daniel Fagerstrom schrieb:

At some point in time, e.g. now ;) we need to decide that we go for 
OSGi. Keeping all roads open at all time means that we just reinvent 
whats allready is standardized in OSGi.


For functionality that we allready have, we must of course respect 
back compability and write wrappers beween what we have and the new 
OSGi based implementations. But for new functionallity I think that 
we should reuse as much as possible of what allready is in OSGi.




I think we should use OSGi *just* for the "core blocks" implementation
which is class loading, versioning and installation and that's it.
But that's just my opinion.



+1

I'd even say that at this point in time, none of the existing blocks 
should be aware of OSGi existence but only Cocoon "Kernel", which uses 
OSGi to manage (load/unload) blocks on the fly.


Why?

Do you have any specific design for achieving this that you are going to 
propose?


People, at this point of time it seem rather pointless to me to impose 
all sorts of restrictions on how we should implement blocks. Instead of 
discussing about how to not implement blocks I would prefer to focus on 
discussing how to implement them or even actually continue implementing 
them ;)


/Daniel

Re: [RT] The impact of using OSGi

[Vadim Gritsenko]

Carsten Ziegeler wrote:

Daniel Fagerstrom schrieb:

At some point in time, e.g. now ;) we need to decide that we go for 
OSGi. Keeping all roads open at all time means that we just reinvent 
whats allready is standardized in OSGi.


For functionality that we allready have, we must of course respect back 
compability and write wrappers beween what we have and the new OSGi 
based implementations. But for new functionallity I think that we should 
reuse as much as possible of what allready is in OSGi.




I think we should use OSGi *just* for the "core blocks" implementation
which is class loading, versioning and installation and that's it.
But that's just my opinion.


+1

I'd even say that at this point in time, none of the existing blocks should be 
aware of OSGi existence but only Cocoon "Kernel", which uses OSGi to manage 
(load/unload) blocks on the fly.


Vadim

Re: Proposal: Make defaults for text serializers UTF-8

[Antonio Gallardo]

Berin Loritsch wrote:


Antonio Gallardo wrote:



BTW, Spanish and Portuguese characters(for example ç,à,á,ñ ) aren't 
supported by utf-8.





This is not what I wanted to state. I wanted to state that Spanish and 
Portuguese IS supported. I use UTF-8 since 2002 in all my work. I copied 
the above sentence from the reply. IN the original mail, the portuguese 
and spanish letter were not properly displayed.


Sorry for the confusion. It was not intentional. :-(

Best Regards,

Antonio Gallardo.





UTF-16 values are:

ç = 00e7
à = 00e0
á = 00e1
ñ = 00f1

For UTF-8 there would be some multibyte representations of them 
because they are above 0080.

Its detailed by this page: http://www.unicode.org/reports/tr26/

The UTF-8 pairs would be:

ç = 0xc3, 0xa7
à = 0xc3, 0xa0
á = 0xc3, 0xa1
ñ = 0xc3, 0xb1

Re: refdoc is about high-level docs (was: SLOP Patch - Added Doktor Comments)

[Bertrand Delacretaz]

Le 10 août 05, à 19:21, Robert Graham a écrit :


...I left in all the old 'javadoc style' comments because I wanted to
test multiple keys per file and just see how doktor would handle it. I
thought of it as a testing strategy...


No problem - it seems like we're on the same wavelength w.r.t the 
"level" of the refdoc. Looking forward to seeing new samples when I 
come back!


-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

FYI: Ful UTF code pages

[Berin Loritsch]

For all who are interested the link here gives you all the codes and 
codepages supported by UTF(8,16,32):


http://www.unicode.org/charts/

Re: Proposal: Make defaults for text serializers UTF-8

[Berin Loritsch]

Antonio Gallardo wrote:



BTW, Spanish and Portuguese characters(for example ç,à,á,ñ ) aren't 
supported by utf-8.



UTF-16 values are:

ç = 00e7
à = 00e0
á = 00e1
ñ = 00f1

For UTF-8 there would be some multibyte representations of them because 
they are above 0080.

Its detailed by this page: http://www.unicode.org/reports/tr26/

The UTF-8 pairs would be:

ç = 0xc3, 0xa7
à = 0xc3, 0xa0
á = 0xc3, 0xa1
ñ = 0xc3, 0xb1

Re: Proposal: Make defaults for text serializers UTF-8

[Joerg Heinicke]

On 10.08.2005 17:41, Vadim Gritsenko wrote:


What do you propose?

src="org.apache.cocoon.serialization.TextSerializer" 
mime-type="text/plain" logger="sitemap.serializer.text">

utf-8



+1 for adding ;charset=utf-8.


Long ago we already had a bug about it: 
http://issues.apache.org/bugzilla/show_bug.cgi?id=26997. It got resolved 
by setting it to duplicate - it seems to early. From what I see we 
should reopen it and get it fixed.


Joerg

Re: Proposal: Make defaults for text serializers UTF-8

[Berin Loritsch]

Niclas Hedhman wrote:


On Wednesday 10 August 2005 21:43, Berin Loritsch wrote:
 


Considering we have a very international user base, and the fact that
more and more projects have to deal with international or special
character, why not make the demo international friendly.
   



The  most amazing part of this proposal is;

Cocoon is a swarm of Europeans with all kinds of funky characters to support, 
yet it comes from a "Good Old American", who is general thought of as 
ignorant to these issue.


Well done Berin !!!
 


Thanks for the compliment.

My main client is the U.S. embassies and consular posts.  When they post 
news it usually has to reference unique characters in the hosting country.

Re: [RT] The impact of using OSGi

[Niclas Hedhman]

On Wednesday 10 August 2005 21:46, Upayavira wrote:
> The question
> is, what if a piece of configuration information is needed by OSGi _and_
> Cocoon, because our use-case is broader than that of OSGi. Should we use
> the manifest.mf file and have our own systems consume that as well as
> OSGi, or alernatively use the block.xml file, and have manifest.mf
> generated from that.

AFAIU, extending the use of the Manifest is "Ok" from both Java's and OSGi's 
point of view. If manifest headers of "Cocoon-XYZ" format is used, I am 
pretty confident that there are no future "issues" with conflicting names.

My own usage pattern is basically; Use a single manifest entry to point to a 
resource within the bundle which contains further information about what one 
is trying to do. But, in the case of "real blocks" I foresee that there are 
some overlap between the "classloading mechanism" needed from OSGi and 
"SiteMap resolutions" provided by Cocoon core, which would suggest that the 
"raw data" is in source form of Cocoon's chosen format, and relevant 
"compilers" creates the necessary division into one, two or more runtime 
parts required.
(This is when you don't want to depend on Maven 1 ;o) )

On a related note, some thought is probably required to "draw the line in the 
sand" for what is Core API and pure implementation. Although startlevels can 
ensure starting orders and that missing classes in a bundle therefor can be 
supplied properly, I get the impression that this is "bad practice" and that 
each bundle should carry all the classes required for its full instantiation.
OSGi will take care of which actual class instance that will be used.
Export of the entire Cocoon codebase of today seems like a bad idea, yet there 
is no good line in the older parts what is api vs implementation. General 
rule; start small and expand with need.


Also, I am in the process of creating a Log4J bundle for OSGi, and I am 
totally open to suggestions on the best way forward with this. The generic 
LogService is indeed very rudimentary, and can potentially be very slow 
(object creation when not needed), but I think there should be an integrated 
solution of both the OSGi LogService as well as some better API, such as 
SLF4J or Jakarta commons-logging, in the same implementation.
I assume that the result will either be hosted at Apache Logging or the new 
Apache OSGi project.


Just my few thoughts on the subject.


Cheers
Niclas

Re: Proposal: Make defaults for text serializers UTF-8

[Niclas Hedhman]

On Wednesday 10 August 2005 21:43, Berin Loritsch wrote:
> Considering we have a very international user base, and the fact that
> more and more projects have to deal with international or special
> character, why not make the demo international friendly.

The  most amazing part of this proposal is;

Cocoon is a swarm of Europeans with all kinds of funky characters to support, 
yet it comes from a "Good Old American", who is general thought of as 
ignorant to these issue.

Well done Berin !!!


Cheers
Niclas

DO NOT REPLY [Bug 35575] - [PATCH] XMLDBSource cannot find SerializerSelector

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35575





--- Additional Comments From [EMAIL PROTECTED]  2005-08-10 19:39 ---
I think the patch for 34940 would also fix this problem:
http://issues.apache.org/bugzilla/show_bug.cgi?id=34940

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: refdoc is about high-level docs (was: SLOP Patch - Added Doktor Comments)

[Robert Graham]

Bertrand,

> Of course the SlopGenerator is a dead simple component, others might
> need much more documentation, but I hope this shows my idea more
> precisely. Sorry about not communicating this better before.

I think that you had already gotten this across, I'm just not entirely
sure how to document some of the components. If you poke around the
SLOP block more, you'll see that at the bottom of every file I've
deveoted an area to doing nearly exactly what you're talking about.

I left in all the old 'javadoc style' comments because I wanted to
test multiple keys per file and just see how doktor would handle it. I
thought of it as a testing strategy albeit a lazy sort of one in that
I didn't really want to remove the old comments either. I isolated a
few issues using this strategy and fixed them. I can go through and
clean the SLOP comments up to something even more refined toward what
you're thinking without and extras, which I assume you'd want.

I'm also pretty much ready to figure out how to order the documents
and will have a sample ready pretty soon.

Robert

Re: Proposal: Make defaults for text serializers UTF-8

[Antonio Gallardo]

Berin Loritsch wrote:


Considering we have a very international user base, and the fact that
more and more projects have to deal with international or special
character, why not make the demo international friendly.

In order to set encoding standards for your mime-type you have to
include the character-encoding after the mime-type.  Ex:

text/html;encoding=utf-8

Without the encoding clue, most browsers assume whatever is the default
for that browser.  In the U.S. it is typically iso-8859-latin.  This bit
us yesterday as we had to make that change to support special characters
again--this time with Cocoon.
 


+1 for cocoon 2.2. In order to keep backward compatibility.

BTW, Spanish and Portuguese characters(for example ç,à,á,ñ ) aren't supported 
by utf-8.

It was just the mail I replied had some encoding problems. See below:

*
This message is in MIME format.  The first part should be readable text,
 while the remaining parts are likely unreadable without MIME-aware tools.

--17432832-1323476517-1123692175=:11582
Content-Type: TEXT/PLAIN; charset="ISO 8859-1"; format=flowed
Content-Transfer-Encoding: 8BIT

Hi. Just couldn't agree with your suggestion as Spanish and Portuguese 
characters(for example ç,à,á,ñ ) aren't supported by utf-8. 
But this is just my opinion...


CarlosN.
*






Best Regards,

Antonio Gallardo.

Re: Proposal: Make defaults for text serializers UTF-8

[Berin Loritsch]

Carlos M. S. Bento Nogueira wrote:

Hi. Just couldn't agree with your suggestion as Spanish and Portuguese 
characters(for example �,�,�,� ) aren't supported by utf-8. But this 
is just my opinion...



You mean like: ñðòóôõö

The Spanish and Portuguese characters probably have a different value in 
UTF-8, but they are there.

Re: Proposal: Make defaults for text serializers UTF-8

[Antonio Gallardo]

Carlos M. S. Bento Nogueira wrote:

Hi. Just couldn't agree with your suggestion as Spanish and Portuguese 
characters(for example �,�,�,� ) aren't supported by utf-8. But this 
is just my opinion...


Sorry, but this is not true. They are supported.

Best Regards,

Antonio Gallardo

Re: Proposal: Make defaults for text serializers UTF-8

[Berin Loritsch]

Vadim Gritsenko wrote:


Leszek Gawron wrote:


Gregor J. Rothfuss wrote:


Leszek Gawron wrote:


Berin Loritsch wrote:


In order to set encoding standards for your mime-type you have to
include the character-encoding after the mime-type.  Ex:

text/html;encoding=utf-8




You probably mean 'charset' parameter [1].


Without the encoding clue, most browsers assume whatever is the 
default
for that browser.  In the U.S. it is typically iso-8859-latin.  
This bit
us yesterday as we had to make that change to support special 
characters

again--this time with Cocoon.


What do you propose?

src="org.apache.cocoon.serialization.TextSerializer" 
mime-type="text/plain" logger="sitemap.serializer.text">

utf-8





+1 for adding ;charset=utf-8.

Vadim

[1] http://www.rfc-editor.org/rfc/rfc2854.txt



Thanks for the correction.  Yes that is exactly what I mean.

Cocoon Forms library... some more questions.

[Max Pfingsthorn]

Hi everyone!

Sorry that I haven't touched base for so long, but I am pretty busy... I've 
been working on Slide a lot and I've been implementing yet another Schema to 
CForms transformation, both for my wonderful employer.
Anyway, I've finally found some time to write some more code and now I've come 
across these few things... I thought it would be nice to get some input from 
you guys:

1. Macro expansion, at library-build-time, definition-build-time or 
instance-build-time? I guess this is a performance thing, both ways: Takes more 
time to instantiate a form, but if a library deep in the inclusion tree 
changes, you don't have to reload all levels on top. Kinda want to avoid what 
bothers me the most with ...

2. Macro inheritance? I would imagine something like:


   
 mylabel
   



   
 firstname
   
   
 lastname
   


Instead of "replaces", I could think of (goes for library-level reuse too):
- replaces: well, completely replace other widget
- base: make a new widget alongside the other one, but take the other as a base
- extends: elaborate on the definition of the other widget, no new widgets 
created

 would give:


  firstname


  lastname


I think we can implement rules for everything the DefinitionBuilders do for 
inheritance (i.e. by defining a label, it replaces the old one, and by defining 
a static selection list it extends the old one, etc...) inside the specific 
DefinitionBuilders. They should do the parsing/setting of the definition 
objects, but the validation should be up to the definition itself. This way, we 
can have partial definitions present in the library objects ready for extension 
and use at the same time.

3. The wiki page said, there was support for parameterized macros, but I don't 
see it... Any pointers?

4. Library object: Should it be a standalone thing or rather a 
AbstractContainerDefinition (like in the whiteboard code)? I don't see the big 
use of it being a widget yet...

5. Deep copying of widget definitions: This needs to be possible to keep the 
definitions stored in the libraries intact. This might be a hassle, especially 
with selection lists and all that extra stuff. Does anyone have an idea how to 
do this without implementing it for every widget?

I am looking forward to some input!

By the way, I know I am behind... But it is still a "long" time to September 
1st, so I might just make it. Next weekend should be free (finally), so I'll be 
coding then. It would be great if we could address some of the issues above 
before that so I can dive in big time ;)

Best regards,

Max Pfingsthorn

Hippo  

Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel  +31 (0)20 5224466
-
[EMAIL PROTECTED] / www.hippo.nl
--

Re: Proposal: Make defaults for text serializers UTF-8

[Carlos M. S. Bento Nogueira]

Hi. Just couldn't agree with your suggestion as Spanish and Portuguese 
characters(for example ?,?,?,? ) aren't supported by utf-8. 
But this is just my opinion...


CarlosN.

On Wed, 10 Aug 2005, Leszek Gawron wrote:


Gregor J. Rothfuss wrote:

Leszek Gawron wrote:


Berin Loritsch wrote:


Considering we have a very international user base, and the fact that
more and more projects have to deal with international or special
character, why not make the demo international friendly.

In order to set encoding standards for your mime-type you have to
include the character-encoding after the mime-type.  Ex:

text/html;encoding=utf-8

Without the encoding clue, most browsers assume whatever is the default
for that browser.  In the U.S. it is typically iso-8859-latin.  This bit
us yesterday as we had to make that change to support special characters
again--this time with Cocoon.


What do you propose?

src="org.apache.cocoon.serialization.TextSerializer" 
mime-type="text/plain" logger="sitemap.serializer.text">

utf-8




you missed the ;encoding=utf-8 for the mime type

and yes, i would be +1 for this

+1. I'm in favour of every setting that makes polish letters work OOTB :)




--

Re: Proposal: Make defaults for text serializers UTF-8

[Vadim Gritsenko]

Leszek Gawron wrote:

Gregor J. Rothfuss wrote:


Leszek Gawron wrote:


Berin Loritsch wrote:


In order to set encoding standards for your mime-type you have to
include the character-encoding after the mime-type.  Ex:

text/html;encoding=utf-8


You probably mean 'charset' parameter [1].



Without the encoding clue, most browsers assume whatever is the default
for that browser.  In the U.S. it is typically iso-8859-latin.  This 
bit
us yesterday as we had to make that change to support special 
characters

again--this time with Cocoon.


What do you propose?

src="org.apache.cocoon.serialization.TextSerializer" 
mime-type="text/plain" logger="sitemap.serializer.text">

utf-8



+1 for adding ;charset=utf-8.

Vadim

[1] http://www.rfc-editor.org/rfc/rfc2854.txt

refdoc is about high-level docs (was: SLOP Patch - Added Doktor Comments)

[Bertrand Delacretaz]

Hi Robert,

Le 1 août 05, à 06:03, Robert Graham a écrit :


I have attached the patch for adding in doktor comments to the SLOP
block...


I've finally found some time to have a closer look, before leaving 
tomorrow.


I haven't applied your changes, because I feel there are too many 
@doktor comments as is. It's not your fault - it's mine, read on.


The main goal, but I probably haven't explained this clearly enough 
before, is not to reinvent javadoc by documenting all the details about 
classes, interfaces, etc. We'll keep javadoc for that, it works fine.


Rather, we want to generate a higher level documentation, which 
explains how to use Cocoon components and which puts together the 
*cocoon-level* information found in various files. It's a bit like the 
new Cocoon stack traces vs. java stack traces.


Taking the slop block as an example again, it has only one component, 
the SlopGenerator, so I'd like refdoc to generate just one document, 
with the following info. In brackets the filenames where the @doktor 
snippets are extracted from:


What is the SlopGenerator (SlopGenerator.java)
What are its configuration and sitemap parameters  (SlopGenerator.java)
How to declare it in a sitemap (samples sitemap.xmap)
Some example pipelines (samples sitemap.xmap)
Example output (dunno how we're going to do this yet, having @doktor 
markers in samples output??)


For configuration and sitemap parameters, the @doktor markers need to 
be next to the lines of code which read them, to remind programmers to 
keep them in sync:


  /** @doktor type:sitemap-parameter name:encoding, description: set 
the encoding to use to read the input file */

  encoding = parameters.getParameter("encoding", null);

Maybe with a shortcut notation, this is a bit heavy. But that's for 
another day.


I think that's it. At this level we don't care about classes, 
interfaces, methods, only Cocoon components and their use.


Adding the necessary markers to the slop code shouldn't take long, and 
this is also a goal: if people need too much work to annotate  existing 
code they won't do it, so we have to stay at a pragmatic level, where 
the gain (a brand new reference document which stays in sync with code 
and examples) is worth the few minutes that it takes to annotate the 
code.


Of course the SlopGenerator is a dead simple component, others might 
need much more documentation, but I hope this shows my idea more 
precisely. Sorry about not communicating this better before.


-Bertrand




smime.p7s
Description: S/MIME cryptographic signature

Re: svn commit: r231243 - /cocoon/trunk/src/documentation/src/content/xdocs/c21-who/content_en.html

[Leszek Gawron]

[EMAIL PROTECTED] wrote:

Author: hepabolu
Date: Wed Aug 10 07:25:06 2005
New Revision: 231243

URL: http://svn.apache.org/viewcvs?rev=231243&view=rev
Log: (empty)

Modified:
cocoon/trunk/src/documentation/src/content/xdocs/c21-who/content_en.html

Modified: 
cocoon/trunk/src/documentation/src/content/xdocs/c21-who/content_en.html
URL: 
http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/src/content/xdocs/c21-who/content_en.html?rev=231243&r1=231242&r2=231243&view=diff
==
--- cocoon/trunk/src/documentation/src/content/xdocs/c21-who/content_en.html 
(original)
+++ cocoon/trunk/src/documentation/src/content/xdocs/c21-who/content_en.html 
Wed Aug 10 07:25:06 2005
@@ -83,6 +83,8 @@
 Matthew Langham (mlangham.at.apache.org)
   
 Tim Larson (tim.at.apache.org)

+
+Helma van der Linden (hepabolu.at.apache.org>

  ^^
a typo here

--
Leszek Gawron  [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: Proposal: Make defaults for text serializers UTF-8

[Leszek Gawron]

Gregor J. Rothfuss wrote:

Leszek Gawron wrote:


Berin Loritsch wrote:


Considering we have a very international user base, and the fact that
more and more projects have to deal with international or special
character, why not make the demo international friendly.

In order to set encoding standards for your mime-type you have to
include the character-encoding after the mime-type.  Ex:

text/html;encoding=utf-8

Without the encoding clue, most browsers assume whatever is the default
for that browser.  In the U.S. it is typically iso-8859-latin.  This bit
us yesterday as we had to make that change to support special characters
again--this time with Cocoon.


What do you propose?

src="org.apache.cocoon.serialization.TextSerializer" 
mime-type="text/plain" logger="sitemap.serializer.text">

utf-8




you missed the ;encoding=utf-8 for the mime type

and yes, i would be +1 for this

+1. I'm in favour of every setting that makes polish letters work OOTB :)

--
Leszek Gawron  [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: Proposal: Make defaults for text serializers UTF-8

[Gregor J. Rothfuss]

Leszek Gawron wrote:

Berin Loritsch wrote:

Considering we have a very international user base, and the fact that
more and more projects have to deal with international or special
character, why not make the demo international friendly.

In order to set encoding standards for your mime-type you have to
include the character-encoding after the mime-type.  Ex:

text/html;encoding=utf-8

Without the encoding clue, most browsers assume whatever is the default
for that browser.  In the U.S. it is typically iso-8859-latin.  This bit
us yesterday as we had to make that change to support special characters
again--this time with Cocoon.


What do you propose?

src="org.apache.cocoon.serialization.TextSerializer" 
mime-type="text/plain" logger="sitemap.serializer.text">

utf-8



you missed the ;encoding=utf-8 for the mime type

and yes, i would be +1 for this

Re: [RT] The impact of using OSGi

[Upayavira]

Carsten Ziegeler wrote:

Daniel Fagerstrom schrieb:

At some point in time, e.g. now ;) we need to decide that we go for 
OSGi. Keeping all roads open at all time means that we just reinvent 
whats allready is standardized in OSGi.


For functionality that we allready have, we must of course respect back 
compability and write wrappers beween what we have and the new OSGi 
based implementations. But for new functionallity I think that we should 
reuse as much as possible of what allready is in OSGi.





I think we should use OSGi *just* for the "core blocks" implementation
which is class loading, versioning and installation and that's it.
But that's just my opinion.


I would say that it would certainly make sense to start there. As time 
passes, the Oscar(whatever) project matures, we can start using more of 
its generic services where they help us. But for now, it probably makes 
sense to just use the necessary.


Regards, Upayavira

Re: Proposal: Make defaults for text serializers UTF-8

[Leszek Gawron]

Berin Loritsch wrote:

Considering we have a very international user base, and the fact that
more and more projects have to deal with international or special
character, why not make the demo international friendly.

In order to set encoding standards for your mime-type you have to
include the character-encoding after the mime-type.  Ex:

text/html;encoding=utf-8

Without the encoding clue, most browsers assume whatever is the default
for that browser.  In the U.S. it is typically iso-8859-latin.  This bit
us yesterday as we had to make that change to support special characters
again--this time with Cocoon.


What do you propose?

src="org.apache.cocoon.serialization.TextSerializer" 
mime-type="text/plain" logger="sitemap.serializer.text">

utf-8


This works just fine. Should we set this in main sitemap?

--
Leszek Gawron  [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: [RT] The impact of using OSGi

[Carsten Ziegeler]

Daniel Fagerstrom schrieb:
> 
> At some point in time, e.g. now ;) we need to decide that we go for 
> OSGi. Keeping all roads open at all time means that we just reinvent 
> whats allready is standardized in OSGi.
> 
> For functionality that we allready have, we must of course respect back 
> compability and write wrappers beween what we have and the new OSGi 
> based implementations. But for new functionallity I think that we should 
> reuse as much as possible of what allready is in OSGi.
> 
> 
I think we should use OSGi *just* for the "core blocks" implementation
which is class loading, versioning and installation and that's it.
But that's just my opinion.

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [RT] The impact of using OSGi

[Upayavira]

Daniel Fagerstrom wrote:

Upayavira wrote:


Carsten Ziegeler wrote:


Daniel Fagerstrom schrieb:


From the discussions last week with Reinhard, Daniel and Upayavira 
I think using block.xml to generate everything else was the 
consensus. See "role of block.xml" in 
http://wiki.apache.org/cocoon/Blockathon2005Report





Hmm, was I really part of that concensus? Like Sylvain I prefer to 
use the OSGi manifest for everything that can be described by that 
and the block.xml for the rest.


Now, IIUC, the rest of you think that such a solution would be 
unpractical because of overlap with gump, compile and deploy time 
dependency descriptors etc. You might very well be right about that, 
but I prefer to wait and see until we actually start to implement it 
before we decide.




I prefer a single source of information about a block: the block.xml -
we can then generate everything else out of. This would also keep us
independent from OSGi.
But you're we can start in any way and then change it later on. For
converting an xml to another xml we just need a stylesheet anyway.




Yes. To change isn't hard. And, I think experience will guide us. Is 
it more important to be able to use standard OSGi bundles within 
Cocoon, or to have Cocoon bundles work outside of Cocoon itself, or to 
have a Cocoon 'block' as being something that has, from a developer's 
point of view, nothing specifically to do with OSGi.



At some point in time, e.g. now ;) we need to decide that we go for 
OSGi. Keeping all roads open at all time means that we just reinvent 
whats allready is standardized in OSGi.


I think that is a different question. I'm all for committing to OSGi, 
after all, we can always roll back as we did with Fortress. Maybe what 
we should do is 'tag' the repository now, before we do anything 
invasive, to make that option simpler. However, I think we have a 
general consensus to push forward with OSGi.


For functionality that we allready have, we must of course respect back 
compability and write wrappers beween what we have and the new OSGi 
based implementations. But for new functionallity I think that we should 
reuse as much as possible of what allready is in OSGi.


Again, I think the question I was answering is different. The question 
is, what if a piece of configuration information is needed by OSGi _and_ 
Cocoon, because our use-case is broader than that of OSGi. Should we use 
the manifest.mf file and have our own systems consume that as well as 
OSGi, or alernatively use the block.xml file, and have manifest.mf 
generated from that.


And that, I think, is a question we don't need to resolve right away.

And these questions we should be able to answer a little further down 
the road.


Exactly, we should let our practical experiences when we start to work 
at it decide.


Yup.

Regards, Upayavira

Proposal: Make defaults for text serializers UTF-8

[Berin Loritsch]

Considering we have a very international user base, and the fact that
more and more projects have to deal with international or special
character, why not make the demo international friendly.

In order to set encoding standards for your mime-type you have to
include the character-encoding after the mime-type.  Ex:

text/html;encoding=utf-8

Without the encoding clue, most browsers assume whatever is the default
for that browser.  In the U.S. it is typically iso-8859-latin.  This bit
us yesterday as we had to make that change to support special characters
again--this time with Cocoon.

TraxSerializer implementation

[BURGHARD Éric]

Hi,

I don't want to just start another thread on this already prolific subject
(was: Suggestion for XHTMLSerializer). Many interesting POV were explained,
and i think that the final idea is that the TraxSerializer simply allow you
to write your serializer in XSL (java seems to be the only possibility for
the moment).

I saw that many commiters are not against this idea, so it's sufficient for
me to submit the TraxSerializer and let the rules of the open source 'wild'
life decide for the future of this component.

I have here a traxserializer which works (since now, only used with saxon)
but it was made in a hurry just to quickly overcome various bugs of
standard serializers.

For simple cases,  is sufficient (no need of a
src attribute), because
1. the serialization works without stylesheet (it works then like the
XMLSerializer do, but with the ability to specify the serialization method)
2. you can provide a default stylesheet in the configuration bloc if you
want

So the configuration block of the component just take the exactly same
parameters than the standard XMLSerializer + a 'method' one (which is
hardcoded in XMLSerializer) + a 'stylesheet' one to provide a default
stylesheet.

For other cases, you can use this form




I only kept the use-request-parameters param, because i never use session or
cookies in transformations and i thought it was sufficient. But should we
allow use-session-info and use-cookies too ? You already know that IMHO the
set of the transformers is a subset of the one of the serializers. That's
why, at least we should have the same expressiveness in TraxTransformer and
TraxSerializer. But perhaps these params were just a mistake for the
Transformer. I don't care in fact. Choose.

That's for the spec, here are the actual limitations
1. It use directly a transformer factory and cache the templates objects
(precompiled stylesheet) by it's own,
2. It does not include a single (but necessary) xalan fix for serialization,
3. It does not test if the choosen xslt-processor handle the serialization
feature.

So basicly, the refactoring targets are the use the XSLTProcessor for 1,
inheritance of AbstractTextSerializer for 2 and the adjunction of the
necessary test for 3.

The AbstractTextSerializer instantiate a transformer factory in the
configure method which will never be used (this is handled by the
XSLProcessor). I see 3 solutions here
a) accomodate ourselves of this 'instantiation for nothing',
b) override the configure method: a copy & paste minus the instantiation
part. but that mean that we change some private attribute to protected in
the AbstractTextSerializer,
c) separate somehow the configure and the instantiation in the
AbstractTextSerializer, so the TraxSerializer can just inherit silently,
d) Refactor the AbstractTextSerializer for using the XSLTProcessor instead
of the factory

I face a more complicated problem with the test (i think that every
xsltprocessor implement the serialize feature but who knows). I need an
access to the getFeature method of the TransformerFactory which is 'damn
well' encapsulated in the XSLTProcessor.
a) augment the XSLTProcessor interface to provide a getTransformerFactory
b) come back to 1a): afterall the instantiation is usefull for this test.

Be my advisers.

Regards.

Re: [RT] The impact of using OSGi

[Daniel Fagerstrom]

Upayavira wrote:


Carsten Ziegeler wrote:


Daniel Fagerstrom schrieb:


From the discussions last week with Reinhard, Daniel and Upayavira 
I think using block.xml to generate everything else was the 
consensus. See "role of block.xml" in 
http://wiki.apache.org/cocoon/Blockathon2005Report




Hmm, was I really part of that concensus? Like Sylvain I prefer to 
use the OSGi manifest for everything that can be described by that 
and the block.xml for the rest.


Now, IIUC, the rest of you think that such a solution would be 
unpractical because of overlap with gump, compile and deploy time 
dependency descriptors etc. You might very well be right about that, 
but I prefer to wait and see until we actually start to implement it 
before we decide.




I prefer a single source of information about a block: the block.xml -
we can then generate everything else out of. This would also keep us
independent from OSGi.
But you're we can start in any way and then change it later on. For
converting an xml to another xml we just need a stylesheet anyway.



Yes. To change isn't hard. And, I think experience will guide us. Is 
it more important to be able to use standard OSGi bundles within 
Cocoon, or to have Cocoon bundles work outside of Cocoon itself, or to 
have a Cocoon 'block' as being something that has, from a developer's 
point of view, nothing specifically to do with OSGi.


At some point in time, e.g. now ;) we need to decide that we go for 
OSGi. Keeping all roads open at all time means that we just reinvent 
whats allready is standardized in OSGi.


For functionality that we allready have, we must of course respect back 
compability and write wrappers beween what we have and the new OSGi 
based implementations. But for new functionallity I think that we should 
reuse as much as possible of what allready is in OSGi.


And these questions we should be able to answer a little further down 
the road.


Exactly, we should let our practical experiences when we start to work 
at it decide.


/Daniel

Re: Initial ECM <-> OSGi bridge checked in

[Daniel Fagerstrom]

Carsten Ziegeler wrote:


Daniel Fagerstrom schrieb:
 

The ECM is given a LoggerManager that uses OSGi's LogService. We may 
consider using an optional LoggerManager service if present, as 
LogService has some limitations (no categories, and no isXxxEnabled 
methods).
 

The OSGi LogService is obviously a little bit limited. In the long term 
we should have a LogService implementation in the Oscar project that 
extends the OSGi LogService with the needed methods. Until then we could 
either use the Knopflerfish extension of the LogService that at least 
contains isXxxEnabled methods. Or, if someone feel like doing it, 
implement an own LogService that fullfills our requirements, that we can 
donate to the Oscar project later.


   


I think we should simply not use the OSGi LogService - we have the
avalon logging infrastructure we can simply continue to use. We
shouldn't change most of our core from one logging system to another.
 

I'm not talking about changing anything within core. The idea is to use 
a LoggerManager implementation that in turn uses an OSGi LogService, see 
o.a.c.core.osgi.OSGiLoggerManager. By using the OSGi LogServce at that 
level we automatically logs that are marked with what bundle it origins 
from and also a standardized API for accessing the log info. This log 
info can in turn be used from e.g. an OSGi console bundle (graphic or 
command line).


Besides the Avalon context we have the Context in the environment, the 
o.a.c.core.Core, o.a.c.core.Settings, 
o.a.c.environment.internal.EnvironmentHelper that gives access to info 
that at least to me seem to cover overlapping concerns. I wonder if 
anyone in the community have a complete understanding of the intended 
roles and lifecycles of all this.


   


I'm trying to move away from the Avalon context. The context will be
replaced by the Core object and the settings object. While the settings
object contains all "settings" :) (like configuration location, logging
settings etc.), the core object is the Cocoon "core" :) The core
provides access to various information as an official api. So basically
everything which is not a setting.
 

I appriciate that you work on tidying things up, still non circular 
definitions of the concern areas would help ;)



The EnvironmentHelper is an *internal* object which is just there to
make the tree processor implementation a little bit easier/faster. It
should not be used directly!
 

I know that it is internal, it is still important when you work on the 
internals, so its role in relation to other context info needs to be 
clarified. Also the combination of dependecy injections in terms of 
context and core and static information in terms of the 
EnvironmentHelper, makes things harder to follow. Also the static 
EnvironmentHelper makes it much more complicated to write unit testing 
code for core components. So I'm starting to think that it is a design 
mistake to have it.


/Daniel

DO NOT REPLY [Bug 36119] - Improvement SetAttributeJXPathBinding and Contribution SetNodeValueJXPathBinding

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36119





--- Additional Comments From [EMAIL PROTECTED]  2005-08-10 14:17 ---
Created an attachment (id=15993)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15993&action=view)
Enhances SetAttributeJXPathBinding and adds SetNodeValueJXPathBinding


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

RE: Architectural concerns

[Kees Broenink]

Hi Jens,

Thanks for your tip. I always was very happy with the basic features of
Cocoon. Never needed frameworks on top of it. But I will give it a try.

Kees

-Oorspronkelijk bericht-
Van: Jens Maukisch [mailto:[EMAIL PROTECTED] 
Verzonden: Wednesday, August 10, 2005 1:14 PM
Aan: dev@cocoon.apache.org; [EMAIL PROTECTED]
Onderwerp: AW: Architectural concerns


Hi,

> Now if you look at this pattern from a higher
> perspective you want to code this as follows:
> 
> - SQL transformer
> - XML generator (no need to use an XSLT file)
> - serialize
> 
> So this means we should allow:
> - not to have a generator at all (yes I thought about the
> consequences)
> - and allow for a generator after a transformer which will 
> simply close
> the previous stream and open a new one

I think we have Flow-Script to do stuff like this?
e.g. do the database related stuff in the flow
and send whatever pipeline you want to produce
some output.

kind regards,
Jens

DO NOT REPLY [Bug 36119] New: - Improvement SetAttributeJXPathBinding and Contribution SetNodeValueJXPathBinding

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36119

   Summary: Improvement SetAttributeJXPathBinding and Contribution
SetNodeValueJXPathBinding
   Product: Cocoon 2
   Version: Current SVN 2.1
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: CocoonForms
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


Two contributions:
-Enhances SetAttributeJXPathBinding.java to be able to set attributes of any
node in the form data.xml
-Adds SetNodeValueJXPathBinding.java, which can set attributes as well as node
values with a XPath expression (includes the two java classes, the
form-conf.xconf and updated docs)

More info in the description.txt in the patch.

I used cvs to check out HEAD of 2.1, like described on the cocoon homepage, I am
not sure if this is correct. If needed (and I get the information how to check
out from svn :-)) I'll supply a patch for SVN.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: [RT] The impact of using OSGi

[Upayavira]

Carsten Ziegeler wrote:

Daniel Fagerstrom schrieb:


From the discussions last week with Reinhard, Daniel and Upayavira I 
think using block.xml to generate everything else was the consensus. See 
"role of block.xml" in http://wiki.apache.org/cocoon/Blockathon2005Report



Hmm, was I really part of that concensus? Like Sylvain I prefer to use 
the OSGi manifest for everything that can be described by that and the 
block.xml for the rest.


Now, IIUC, the rest of you think that such a solution would be 
unpractical because of overlap with gump, compile and deploy time 
dependency descriptors etc. You might very well be right about that, but 
I prefer to wait and see until we actually start to implement it before 
we decide.




I prefer a single source of information about a block: the block.xml -
we can then generate everything else out of. This would also keep us
independent from OSGi.
But you're we can start in any way and then change it later on. For
converting an xml to another xml we just need a stylesheet anyway.


Yes. To change isn't hard. And, I think experience will guide us. Is it 
more important to be able to use standard OSGi bundles within Cocoon, or 
to have Cocoon bundles work outside of Cocoon itself, or to have a 
Cocoon 'block' as being something that has, from a developer's point of 
view, nothing specifically to do with OSGi.


And these questions we should be able to answer a little further down 
the road.


Regards, Upayavira

Re: Initial ECM <-> OSGi bridge checked in

[Carsten Ziegeler]

Daniel Fagerstrom schrieb:
>>The ECM is given a LoggerManager that uses OSGi's LogService. We may 
>>consider using an optional LoggerManager service if present, as 
>>LogService has some limitations (no categories, and no isXxxEnabled 
>>methods).
> 
> 
> The OSGi LogService is obviously a little bit limited. In the long term 
> we should have a LogService implementation in the Oscar project that 
> extends the OSGi LogService with the needed methods. Until then we could 
> either use the Knopflerfish extension of the LogService that at least 
> contains isXxxEnabled methods. Or, if someone feel like doing it, 
> implement an own LogService that fullfills our requirements, that we can 
> donate to the Oscar project later.
> 
I think we should simply not use the OSGi LogService - we have the
avalon logging infrastructure we can simply continue to use. We
shouldn't change most of our core from one logging system to another.

> 
> Besides the Avalon context we have the Context in the environment, the 
> o.a.c.core.Core, o.a.c.core.Settings, 
> o.a.c.environment.internal.EnvironmentHelper that gives access to info 
> that at least to me seem to cover overlapping concerns. I wonder if 
> anyone in the community have a complete understanding of the intended 
> roles and lifecycles of all this.
> 
I'm trying to move away from the Avalon context. The context will be
replaced by the Core object and the settings object. While the settings
object contains all "settings" :) (like configuration location, logging
settings etc.), the core object is the Cocoon "core" :) The core
provides access to various information as an official api. So basically
everything which is not a setting.
The EnvironmentHelper is an *internal* object which is just there to
make the tree processor implementation a little bit easier/faster. It
should not be used directly!

Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [RT] The impact of using OSGi

[Carsten Ziegeler]

Daniel Fagerstrom schrieb:

>> From the discussions last week with Reinhard, Daniel and Upayavira I 
>>think using block.xml to generate everything else was the consensus. See 
>>"role of block.xml" in http://wiki.apache.org/cocoon/Blockathon2005Report
> 
> 
> Hmm, was I really part of that concensus? Like Sylvain I prefer to use 
> the OSGi manifest for everything that can be described by that and the 
> block.xml for the rest.
> 
> Now, IIUC, the rest of you think that such a solution would be 
> unpractical because of overlap with gump, compile and deploy time 
> dependency descriptors etc. You might very well be right about that, but 
> I prefer to wait and see until we actually start to implement it before 
> we decide.
> 
I prefer a single source of information about a block: the block.xml -
we can then generate everything else out of. This would also keep us
independent from OSGi.
But you're we can start in any way and then change it later on. For
converting an xml to another xml we just need a stylesheet anyway.

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: Architectural concerns

[Torsten Curdt]

And what about the root tag?
You want to keep the pipeline well-formed.



Well Cocoon does not garantuee this. It is a common mistake (did it
myself quite often) to forget in a XSLT stylesheet to always set a  
root

tag (...).


That's true ...but still you want or even
need the pipelines to be well-formed ;)


Cocoon is *streaming* the XML through the pipelines.
That's what you would expect from a today's XML pipeline
architecture ...which is also the reason why you cannot
react on XML values inside the stream from the sitemap
level without buffering the whole process.



I was thinking out-of-the-box about functional/conceptual  
requirements.
Your reply is about technical implemention/performance issues. Of  
course
these are sometimes hard to separate because you cannot build  
something
which is impossible (my computer still makes no breakfast). But  
really,
if you take a step back it is hard to explain to new XML pipeline  
users

why they can select on a request parameter but not on a XML field.


It might be something we have to explain to a user
but we have a *concept* of streaming pipelines so...
I am not sure if this is just an implementation
detail ...but anyway

cheers
--
Torsten


PGP.sig
Description: This is a digitally signed message part

AW: Architectural concerns

[Jens Maukisch]

Hi,

> Now if you look at this pattern from a higher
> perspective you want to code this as follows:
> 
> - SQL transformer
> - XML generator (no need to use an XSLT file)
> - serialize
> 
> So this means we should allow:
> - not to have a generator at all (yes I thought about the 
> consequences)
> - and allow for a generator after a transformer which will 
> simply close
> the previous stream and open a new one

I think we have Flow-Script to do stuff like this?
e.g. do the database related stuff in the flow
and send whatever pipeline you want to produce
some output.

kind regards,
Jens

RE: Architectural concerns

[Kees Broenink]

Hi Torsten,

Thanks for your reply.

> And what about the root tag?
> You want to keep the pipeline well-formed.

Well Cocoon does not garantuee this. It is a common mistake (did it
myself quite often) to forget in a XSLT stylesheet to always set a root
tag (...).

> Cocoon is *streaming* the XML through the pipelines.
> That's what you would expect from a today's XML pipeline
> architecture ...which is also the reason why you cannot
> react on XML values inside the stream from the sitemap
> level without buffering the whole process.

I was thinking out-of-the-box about functional/conceptual requirements.
Your reply is about technical implemention/performance issues. Of course
these are sometimes hard to separate because you cannot build something
which is impossible (my computer still makes no breakfast). But really,
if you take a step back it is hard to explain to new XML pipeline users
why they can select on a request parameter but not on a XML field.

Regards,
Kees


-Oorspronkelijk bericht-
Van: Torsten Curdt [mailto:[EMAIL PROTECTED] 
Verzonden: Wednesday, August 10, 2005 12:36 PM
Aan: dev@cocoon.apache.org
Onderwerp: Re: Architectural concerns



> Now to me the first generator is already a farce. I made an SQL 
> transformer that simply accepts the query as parameter in stead of
> using
> the XML stream.

I always thought it would be better to have a sql
query being executed *before* the transformation starts.
So from that point of view this does makes sense.

Altough... having sql statements inside the sitemap! *shiver*

> So this means we should allow:
> - not to have a generator at all (yes I thought about the
> consequences)

?



> - generator: starts a new stream (thus ignoring previous stream if
> present)
> - transformer: changes a stream (which could be empty at the  
> beginning)
> - serializer: ends the stream

And what about the root tag?
You want to keep the pipeline well-formed.

Sorry, not excited here.

> Related to this issue is the Cocoon Aggregate statement

Have a look into the cinclude transformer



> 2. selectors are evaluated before the pipeline is executed
>
> This basically means you can select on global, request and session
> fields because these are already set. But of course you also want to
> react on XML values in the stream. That is what you expect from an XML
> pipeline architecture.

Cocoon is *streaming* the XML through the pipelines.
That's what you would expect from a today's XML pipeline
architecture ...which is also the reason why you cannot
react on XML values inside the stream from the sitemap
level without buffering the whole process.

> In short: I want to be able to choose different transformers depending
> on the elements/attributes placed in the stream by the previous
> transformer.

Maybe you want to have a look into cocoon 1 :-P

cheers
--
Torsten

Re: Architectural concerns

[Torsten Curdt]

Now to me the first generator is already a farce. I made an SQL
transformer that simply accepts the query as parameter in stead of  
using

the XML stream.


I always thought it would be better to have a sql
query being executed *before* the transformation starts.
So from that point of view this does makes sense.

Altough... having sql statements inside the sitemap! *shiver*


So this means we should allow:
- not to have a generator at all (yes I thought about the  
consequences)


?




- generator: starts a new stream (thus ignoring previous stream if
present)
- transformer: changes a stream (which could be empty at the  
beginning)

- serializer: ends the stream


And what about the root tag?
You want to keep the pipeline well-formed.

Sorry, not excited here.


Related to this issue is the Cocoon Aggregate statement


Have a look into the cinclude transformer




2. selectors are evaluated before the pipeline is executed

This basically means you can select on global, request and session
fields because these are already set. But of course you also want to
react on XML values in the stream. That is what you expect from an XML
pipeline architecture.


Cocoon is *streaming* the XML through the pipelines.
That's what you would expect from a today's XML pipeline
architecture ...which is also the reason why you cannot
react on XML values inside the stream from the sitemap
level without buffering the whole process.


In short: I want to be able to choose different transformers depending
on the elements/attributes placed in the stream by the previous
transformer.


Maybe you want to have a look into cocoon 1 :-P

cheers
--
Torsten


PGP.sig
Description: This is a digitally signed message part

Re: Initial ECM <-> OSGi bridge checked in

[Daniel Fagerstrom]

Sylvain Wallez wrote:


Hi all,

I committed an initial ECM <-> OSGi bridge in 
src/org/apache/cocoon/core/osgi.


Cool!

This code is untested and there are still some pending points, but I 
wanted to share it ASAP so that we can discuss these issues.


What we have there is a ServiceManagerActivator that will create an 
ECM++. In this ECM, components that have exported="true" on their 
configuration are registered as OSGi services.


Also, the parent of this ECM is an OSGiServiceManager that looks up 
non-local components as OSGi services.


Ok

The ECM is given a LoggerManager that uses OSGi's LogService. We may 
consider using an optional LoggerManager service if present, as 
LogService has some limitations (no categories, and no isXxxEnabled 
methods).


The OSGi LogService is obviously a little bit limited. In the long term 
we should have a LogService implementation in the Oscar project that 
extends the OSGi LogService with the needed methods. Until then we could 
either use the Knopflerfish extension of the LogService that at least 
contains isXxxEnabled methods. Or, if someone feel like doing it, 
implement an own LogService that fullfills our requirements, that we can 
donate to the Oscar project later.


The main pending point is the avalon context for the created ECM. 
Cocoon places a lot of environment-related information there that I 
currently don't know where to get from. Maybe this should be obtained 
from the Cocoon core bundle?


It could possibly be exposed as a service from the Cocoon core bundle.

At some point we need to take a deeper look at the various contexts in 
Cocoon. One of the major hurdles during my various core related work the 
last months have been to understand (or rather not break :/ ) context 
info in Cocoon.


Besides the Avalon context we have the Context in the environment, the 
o.a.c.core.Core, o.a.c.core.Settings, 
o.a.c.environment.internal.EnvironmentHelper that gives access to info 
that at least to me seem to cover overlapping concerns. I wonder if 
anyone in the community have a complete understanding of the intended 
roles and lifecycles of all this.


At least we need to write documentation on how all this works, so that 
not each person that try to do core work needs to read tons of code to 
"understand" this mess. Preferably we should refactor it to something 
more comprehensible.


Sorry for my rant about Cocoon internals, but I have spent weeks in 
fighting with them.


   --- o0o ---

Anyway, cool work. The next step, as soon as we have found a way to get 
the context info, should be to apply the stuff on some suitable block.


/Daniel

Architectural concerns

[Kees Broenink]

Hi all,

We have seen some very interesting discussions about XSL as serializer.
Probably most of you are tired of another architectural discussion. But
for those who love some 'verbal action' I will tell you my experiences
with Cocoon. Sorry for the lengthy story.
I am an experienced Cocoon user and also created some complicated new
Transformers for our XML Server product. There were two major problems
with Cocoon I encountered: 
1. only one generator allowed per pipeline
2. selectors are evaluated before the pipeline is executed

1. only one generator allowed per pipeline

At forehand I want to make clear that I agree with the basic components
of a pipeline: Generator, Transformer and Serializer. 
Think about the following very common pattern with Web requests:
- do something in a backend system (e.g. insert a record in a database)
and on success return a new unrelated piece of HTML

Suppose the data of the client does not have XML but only request
parameters. Now map this to Cocoon:
- generator that builds the SQL query using request parameters
- SQL transformer (adjusted to throw an exception on error)
- XSLT that creates a new piece of HTML unrelated to the previous
transformer (template match='/') 
- serialize

Now to me the first generator is already a farce. I made an SQL
transformer that simply accepts the query as parameter in stead of using
the XML stream. Now if you look at this pattern from a higher
perspective you want to code this as follows:

- SQL transformer
- XML generator (no need to use an XSLT file)
- serialize

So this means we should allow:
- not to have a generator at all (yes I thought about the consequences)
- and allow for a generator after a transformer which will simply close
the previous stream and open a new one

In other words: the concept of a NOP generator and the concept of more
than one serializer-transformer stream in one pipeline. This will still
keep the definition of the three concepts in place but makes them less
rigid:

- generator: starts a new stream (thus ignoring previous stream if
present)
- transformer: changes a stream (which could be empty at the beginning)
- serializer: ends the stream

Related to this issue is the Cocoon Aggregate statement. It is very
limiting that in Cocoon you must start with the aggregate. Why is the
following patterns not allowed:
- start a stream (e.g. document plus metadata)
- aggregate
  - part 1: transforms the stream (e.g. index based on metadata +
document title)
  - part 2: transforms the stream (e.g. document itself where links
became HTML anchors)
- serialize

I know this is a separate issue. If the Aggregate concept was mapped to
the Transformer concept, it could work. But also here you can see the
rigid implementation of the three basic concepts. Because a Part points
to another pipeline, and a pipeline always starts a stream, the
aggregate cannot take the existing stream into account.
People solve these limitations by using multiple pipelines, most of the
time with xinclude of cinclude. In that case the transformer basically
becomes a generator. It is clear that this is a workaround. Also note
that you will loose the {0}, {1} values of the orignal URI when you call
another pipeline.
My solution for our product is that all components are transformers and
I have a standard NOP generator (if the client does not send XML). But I
would like to use the standard Cocoon generators...

2. selectors are evaluated before the pipeline is executed

This basically means you can select on global, request and session
fields because these are already set. But of course you also want to
react on XML values in the stream. That is what you expect from an XML
pipeline architecture.
In short: I want to be able to choose different transformers depending
on the elements/attributes placed in the stream by the previous
transformer.

Thanks for your patience.

Kees