headers
Stephan Coboos | 1 Jul 2004 08:44
Picon

Filter like in servlet container

Hello,

why not implement a filter system like in a servlet container exists to 
filter the request and the response? Because using the filter of the 
servlet-container there is a bindig between cocoon and the servlet 
container necessary. This filter technique would be useful eg for 
closing transactions after view generation (like hibernate and some 
others) or to simply plug-in a login mechanism (just a few examples out 
of many).

What do you think about it?

Regards
Stephan
Permalink | Reply | 0 comments |
headers
Colin Paul Adams | 1 Jul 2004 10:32
Picon
Picon
Favicon

CForms - strict DTD and xhtml

>>>>> "Joerg" == Joerg Heinicke <joerg.heinicke <at> gmx.de> writes:

    >> ones (like using transitional DTD rather than CSS - the latter
    >> approach makes styling customization easier).

    Joerg> You are really nagging on this issue, aren't you? ;-)
    Joerg> http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=108862151322458&w=4

Drip. Drip. Drip.
Look - a hollow's appeared in that stone! (no hole yet, though)

I checked out all the samples - since everyone of them is using the
Transitional DTD, that's not much of a test for your claim to
adherence to the strict DTD. Inspecting the source code by hand
suggests it might well be a valid claim.

I think that today i will probably change my own template to use the
4.01 strict DTD, to further check the validation issues, and also so
that I can progress with my application.

There are one or two of the samples do not completely validate (ignoring
the xmlns:fi issue), and the forms-gui one is nothing like (but I
think you are already well aware of that).

Have you looked at all the additional comments I made to bug #29854
yesterday? I surmise that this xmlns:fi issue is probably the same
bug (or at least, closely related to it - in any case it is produced
by the FormsTransformer).

Visual inspection also shows one other thing that would be a problem
(Continue reading)

Permalink | Reply | 501 comments |
headers
Leszek Gawron | 1 Jul 2004 11:52
Picon

CIncludeTransformer issues

I want to build a cform out of several reusable parts. Consider a 
contractor, user, company having an address. So i created a file that 
contains only address widgets
> <?xml version="1.0" encoding="utf-8"?>
> <fd:widgets xmlns:fd="http://apache.org/cocoon/forms/1.0#definition" xmlns:i18n="http://apache.org/cocoon/i18n/2.1">
> <fd:field id="street">
>  <fd:label>Ulica</fd:label>
>  <fd:datatype base="string"/>
> </fd:field>
> <fd:field id="building">
>  <fd:label>Numer budynku</fd:label>
>  <fd:datatype base="string"/>
> </fd:field>
> <fd:field id="apartment">
>  <fd:label>Numer lokalu</fd:label>
>  <fd:datatype base="string"/>
> </fd:field>
>  <fd:field id="postalCode">
>  <fd:label>Kod pocztowy</fd:label>
> <fd:datatype base="string"/>
> </fd:field>
>  <fd:field id="city">
>  <fd:label>Miejscowosc</fd:label>
> <fd:datatype base="string"/>
> </fd:field>
> </fd:widgets>

1. Is there some syntax that allows to do that in cinclude:
<xi:include 
href="editAddress-def.xml#xmlns(fd=http://apache.org/cocoon/forms/1.0#definition)
(Continue reading)

Permalink | Reply | 8 comments |
headers
Leszek Gawron | 1 Jul 2004 11:59
Picon

Re: CIncludeTransformer issues

Leszek Gawron wrote:

> I want to build a cform out of several reusable parts. Consider a 
> contractor, user, company having an address. So i created a file that 
> contains only address widgets
> 
>> <?xml version="1.0" encoding="utf-8"?>
>> <fd:widgets xmlns:fd="http://apache.org/cocoon/forms/1.0#definition" 
>> xmlns:i18n="http://apache.org/cocoon/i18n/2.1">
>> <fd:field id="street">
>>  <fd:label>Ulica</fd:label>
>>  <fd:datatype base="string"/>
>> </fd:field>
>> <fd:field id="building">
>>  <fd:label>Numer budynku</fd:label>
>>  <fd:datatype base="string"/>
>> </fd:field>
>> <fd:field id="apartment">
>>  <fd:label>Numer lokalu</fd:label>
>>  <fd:datatype base="string"/>
>> </fd:field>
>>  <fd:field id="postalCode">
>>  <fd:label>Kod pocztowy</fd:label>
>> <fd:datatype base="string"/>
>> </fd:field>
>>  <fd:field id="city">
>>  <fd:label>Miejscowosc</fd:label>
>> <fd:datatype base="string"/>
>> </fd:field>
>> </fd:widgets>
(Continue reading)

Permalink | Reply | 7 comments |
headers
Torsten Curdt | 1 Jul 2004 12:47
Gravatar

Re: CIncludeTransformer issues

>> 2. If not would you accept the path that allows to do strip-root in 
>> CIncludeTransformer - it would also be much faster than select="/root/*"
> 
> 
> The PATCH not the path

big +1

...see the archives:

I wanted to add this feature but
worked around due to time constraints.

Having a strip-root parameter on the
CInclude transformer makes sense IMO.

cheers
--
Torsten
Permalink | Reply | 6 comments |
headers
Vadim Gritsenko | 1 Jul 2004 12:59

Re: Cocoon is not gump!

Ralph Goers wrote:

> Frankly, this is where maven would really help as all these jars would 
> not be included with the Cocoon distribution but be coming from a 
> central repository.  It would then be just as easy to put a jar of the 
> source in the repository as the binary jar. This would make the 
> problem just disappear.

Just wondering - who will put sources into the maven repository and who 
will maintain it for 30 years?

Vadim
Permalink | Reply | 5 comments |
headers
Joerg Heinicke | 1 Jul 2004 13:46
Picon
Picon

question on UnionBinding

Starting with the question: Does it make sense to process all sub bindings of a
UnionBinding?

At the moment the UnionBinding behaves just like a ContextBinding, all sub
bindings are processed. While the processing of a UnionWidget depends on the
caseWidget the same is not true for the binding.

My use case: I have different cases that need the same widget to be displayed
and later on saved back to bean. But the value is not saved to the bean only for
the current case but for all cases and so my case5 always wins, though another
case might have been selected.

My binding:

    <fb:class id="voucher-class">
      <fb:value id="voucher" path="voucherAvailable" direction="save"/>
    </fb:class>
    <fb:union id="eventData" path=".">
      <fb:struct id="some other cases that don't need the voucher widget">
        ...
      </fb:struct>
      <fb:struct id="case1" path=".">
        <fb:new id="voucher-class"/>
      </fb:struct>
      <fb:struct id="case2" path=".">
        <fb:new id="voucher-class"/>
      </fb:struct>
      <fb:struct id="case3" path=".">
        <fb:new id="voucher-class"/>
      </fb:struct>
(Continue reading)

Permalink | Reply | 9 comments |
headers
Leszek Gawron | 1 Jul 2004 14:04
Picon

Re: CIncludeTransformer issues

Torsten Curdt wrote:
>>> 2. If not would you accept the path that allows to do strip-root in 
>>> CIncludeTransformer - it would also be much faster than select="/root/*"
>>
>>
>>
>> The PATCH not the path
> 
> 
> big +1
> 
> ...see the archives:
> 
> I wanted to add this feature but
> worked around due to time constraints.
> 
> Having a strip-root parameter on the
> CInclude transformer makes sense IMO.
I will try to implement that today but this will need revising as there is 
some kind of magic in the code (paralell fetching or sth)

--

-- 
Leszek Gawron                                      lgawron <at> mobilebox.pl
Permalink | Reply | 0 comments |
headers
Ralph Goers | 1 Jul 2004 15:14
Favicon

Re: Cocoon is not gump!

What do you mean by maintain?

As for who will put the source in, it would be whoever puts the binary jar 
in - they should come in and go out together.

At 7/1/2004  03:59 AM, you wrote:
>Ralph Goers wrote:
>
>>Frankly, this is where maven would really help as all these jars would 
>>not be included with the Cocoon distribution but be coming from a central 
>>repository.  It would then be just as easy to put a jar of the source in 
>>the repository as the binary jar. This would make the problem just disappear.
>
>
>Just wondering - who will put sources into the maven repository and who 
>will maintain it for 30 years?
>
>Vadim
>
Permalink | Reply | 3 comments |
headers
Tim Larson | 1 Jul 2004 16:09

Re: question on UnionBinding

On Thu, Jul 01, 2004 at 11:46:55AM +0000, Joerg Heinicke wrote:
> Starting with the question: Does it make sense to process all sub bindings of a
> UnionBinding?
> 
> At the moment the UnionBinding behaves just like a ContextBinding, all sub
> bindings are processed. While the processing of a UnionWidget depends on the
> caseWidget the same is not true for the binding.
> 
> My use case: I have different cases that need the same widget to be displayed
> and later on saved back to bean. But the value is not saved to the bean only for
> the current case but for all cases and so my case5 always wins, though another
> case might have been selected.
<snip example/>
> The usage of voucherAvailable on the bean is exclusive, so I don't want to have
> 5 fields were one would be sufficient.
> 
> Was the UnionBinding implemented that way because nobody thought about my use
> case or was there a use case for the current behaviour?

I do not have time to dig in the code right now, but this looks like a bug
(oversight) that needs fixed.  Only the current case should be processed.

--Tim Larson
Permalink | Reply | 1 comment |

Gmane