You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@lenya.apache.org by Jürgen Ragaller <ra...@null-oder-eins.ch> on 2007/09/13 14:36:18 UTC
[2.0] - cform question
Hi
I have to implement a rather complex contact form in lenya.
It would be nice to benefit from the cocoon cform features
(validation, i18n, flow, etc.).
The modules I looked at for inspiration were cforms (using cforms for
a resource-type/usecase) and contactform (using jx/java without a
cform).
I'm a still a bit confused here
- The cforms module has a custom Flowscript featuring a
customLoopFlow and a customSubmitFlow
Is it a customSubmitFlow I have to write in my case (and reqister the
form Definition / Binding / View there)?
In the usecase framework docu I read that «Some special complex
usecases might require a custom flowscript, in this case you can't
use this framework». The customSubmitFlow mechanism seems to be an
option to write a custom flow for a 2.0 usecase - or do I walk in the
wrong direction?
Thanks a lot for hints about the best practise to write a contact
form module using a cform (if possible)!
Jürgen
null-oder-eins GmbH
web & graphic design
Anna Heerstrasse 14
8057 Zürich
www.null-oder-eins.ch
Tel +41 44 350 56 26
Fax +41 44 350 56 27
Jürgen Ragaller
ragaller@null-oder-eins.ch
Skype: callto://ragaller
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Jörn Nettingsmeier <ne...@apache.org>.
hi jürgen!
Jürgen Ragaller wrote:
> Hi
>
>
> I have to implement a rather complex contact form in lenya.
> It would be nice to benefit from the cocoon cform features (validation,
> i18n, flow, etc.).
>
> The modules I looked at for inspiration were cforms (using cforms for a
> resource-type/usecase) and contactform (using jx/java without a cform).
>
> I'm a still a bit confused here
> - The cforms module has a custom Flowscript featuring a customLoopFlow
> and a customSubmitFlow
>
> Is it a customSubmitFlow I have to write in my case (and reqister the
> form Definition / Binding / View there)?
yes. these two functions are meant to sneak in custom flow code without
having to replicate all the boilerplate stuff around it.
> In the usecase framework docu I read that «Some special complex usecases
> might require a custom flowscript, in this case you can't use this
> framework». The customSubmitFlow mechanism seems to be an option to
> write a custom flow for a 2.0 usecase - or do I walk in the wrong
> direction?
those docs should be updated. i think as it is now, pretty much
everything can be done using the genericc usecases.js flow (and custom
loop and submit functions).
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Jürgen Ragaller <ra...@null-oder-eins.ch>.
Am 18.09.2007 um 08:45 schrieb Jörn Nettingsmeier:
> Jürgen Ragaller wrote:
>> I managed to setup a cform, writing a customLoopFlow - the
>> validation is working.
>> But the working cform has the design of the login screen (no tabs
>> menu etc.).
>> To get the cform displayed inside a lenya page envelope I created
>> a usecase document
>> using the uri:
>> usecase=mymodulename.event&lenya.usecase=usecasedocument.create
>> (as it is done in the contactform module).
>
> i guess you wrote a custom module for your usecase?
Yes
> if so, it's probably more effective to implement a lenya page
> "view" locally and not delegate to usecasedocument. all you need to
> do is have the publication render the page and then sneak in your
> extra content (check out the tinymce module sitemap, it uses the
> same approach).
> that way, you don't have to pile usecases on top of each other, and
> it's probably faster.
>
Thanks for the pointer!
Jürgen
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Jürgen Ragaller wrote:
>
> I managed to setup a cform, writing a customLoopFlow - the validation is
> working.
> But the working cform has the design of the login screen (no tabs menu
> etc.).
>
> To get the cform displayed inside a lenya page envelope I created a
> usecase document
> using the uri:
> usecase=mymodulename.event&lenya.usecase=usecasedocument.create
> (as it is done in the contactform module).
i guess you wrote a custom module for your usecase?
if so, it's probably more effective to implement a lenya page "view"
locally and not delegate to usecasedocument. all you need to do is have
the publication render the page and then sneak in your extra content
(check out the tinymce module sitemap, it uses the same approach).
that way, you don't have to pile usecases on top of each other, and it's
probably faster.
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Joern Nettingsmeier <ne...@folkwang-hochschule.de>.
Jürgen Ragaller wrote:
>
> Am 18.09.2007 um 10:48 schrieb Jörn Nettingsmeier:
>
>> Jürgen Ragaller wrote:
>>> I thought I'd use the usecasedocument module as it is done in the
>>> contactform module. What I like about it is, that cocoon.xconf only
>>> has to be patched once for the usecase (no need for samples etc.).
>>> And such a usecasedocument can be moved in the site structure like
>>> any other resource type.
>>
>> you are right. on second thought, a usecasedocument is certainly more
>> appropriate for your usage scenario.
>>
>>> But the usecasedocument module sitemap unfortunately eats up the dojo
>>> scripts...
>>
>> hmm. i just looked into this, and i think the usecasedocument sitemap
>> knows way too much about cforms-specific stuff... if i understand its
>> purpose correctly, all it should to is wrap a usecase invocation and
>> subsequent view as a lenya document - no reason at all it should be
>> concerned with cforms intricacies... but then, i haven't used it yet
>> or tried to fix it, so talk is cheap.
>>
>
> I just read
> http://wiki.apache.org/lenya/HowToCFormsInLenya2.0
> by bob
>
> It seems to be another approach how to get cforms working (my confusion
> now grows again...)
>
> Has anybody achieved to get cforms working in a lenya page-envelope?
> Maybe even as usecasedocument?
this document is slightly outdated and describes a "from scratch"
approach. your best bet should be to look at the cforms module *and* to
look around on the cocoon lists *a lot*. jeremy quinn has made huge
improvements to cforms during the last year, and afaik nobody has
reviewed these from a lenya pov yet. so you might find that the lenya
cforms module does things in odd ways that contradict the way the cocoon
folks are now doing it...
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
Kurt is up in Heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Jürgen Ragaller <ra...@null-oder-eins.ch>.
Am Sep 19, 2007 um 1:24 schrieb Bob Harner:
>> I just read
>> http://wiki.apache.org/lenya/HowToCFormsInLenya2.0
>> by bob
>
> by Thorsten, actually.
sorry again.
Jürgen
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Jürgen Ragaller <ra...@null-oder-eins.ch>.
Am 19.09.2007 um 08:51 schrieb Thorsten Scherler:
> On Tue, 2007-09-18 at 19:24 -0400, Bob Harner wrote:
>>> I just read
>>> http://wiki.apache.org/lenya/HowToCFormsInLenya2.0
>>> by bob
>>
>> by Thorsten, actually.
Ah, yes - just saw that in the revision history.
>
> jeje, then I understand the confusion.
>
> This page reflects the beginning of the cform example in 2005. Like
> said
> has been a while I played with cforms and back then I started the wiki
> page.
>
Thanks for the orientation
Jürgen
null-oder-eins GmbH
web & graphic design
Anna Heerstrasse 14
8057 Zürich
www.null-oder-eins.ch
Tel +41 44 350 56 26
Fax +41 44 350 56 27
Jürgen Ragaller
ragaller@null-oder-eins.ch
Skype: callto://ragaller
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Tue, 2007-09-18 at 19:24 -0400, Bob Harner wrote:
> > I just read
> > http://wiki.apache.org/lenya/HowToCFormsInLenya2.0
> > by bob
>
> by Thorsten, actually.
jeje, then I understand the confusion.
This page reflects the beginning of the cform example in 2005. Like said
has been a while I played with cforms and back then I started the wiki
page.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Bob Harner <bo...@gmail.com>.
> I just read
> http://wiki.apache.org/lenya/HowToCFormsInLenya2.0
> by bob
by Thorsten, actually.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Jürgen Ragaller <ra...@null-oder-eins.ch>.
Am 18.09.2007 um 10:48 schrieb Jörn Nettingsmeier:
> Jürgen Ragaller wrote:
>> I thought I'd use the usecasedocument module as it is done in the
>> contactform module. What I like about it is, that cocoon.xconf
>> only has to be patched once for the usecase (no need for samples
>> etc.). And such a usecasedocument can be moved in the site
>> structure like any other resource type.
>
> you are right. on second thought, a usecasedocument is certainly
> more appropriate for your usage scenario.
>
>> But the usecasedocument module sitemap unfortunately eats up the
>> dojo scripts...
>
> hmm. i just looked into this, and i think the usecasedocument
> sitemap knows way too much about cforms-specific stuff... if i
> understand its purpose correctly, all it should to is wrap a
> usecase invocation and subsequent view as a lenya document - no
> reason at all it should be concerned with cforms intricacies... but
> then, i haven't used it yet or tried to fix it, so talk is cheap.
>
I just read
http://wiki.apache.org/lenya/HowToCFormsInLenya2.0
by bob
It seems to be another approach how to get cforms working (my
confusion now grows again...)
Has anybody achieved to get cforms working in a lenya page-envelope?
Maybe even as usecasedocument?
Jürgen
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Jürgen Ragaller wrote:
> I thought I'd use the usecasedocument module as it is done in the
> contactform module. What I like about it is, that cocoon.xconf only has
> to be patched once for the usecase (no need for samples etc.). And such
> a usecasedocument can be moved in the site structure like any other
> resource type.
you are right. on second thought, a usecasedocument is certainly more
appropriate for your usage scenario.
> But the usecasedocument module sitemap unfortunately eats up the dojo
> scripts...
hmm. i just looked into this, and i think the usecasedocument sitemap
knows way too much about cforms-specific stuff... if i understand its
purpose correctly, all it should to is wrap a usecase invocation and
subsequent view as a lenya document - no reason at all it should be
concerned with cforms intricacies... but then, i haven't used it yet or
tried to fix it, so talk is cheap.
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Jürgen Ragaller <ra...@null-oder-eins.ch>.
Good morning, Jörn!
Am 18.09.2007 um 08:49 schrieb Joern Nettingsmeier:
> Jürgen Ragaller wrote:
>> Am Sep 17, 2007 um 20:43 schrieb Jürgen Ragaller:
>>>
>>> The next thing to find out is how to get the dojo javascript
>>> stuff and cocoon form css in the html head...
>>>
>> Here is what I found out about the above problem:
>> In usecasedocument/sitemap.xmap the transformation forms-samples-
>> styling.xsl inserts the dojo scripts but after the xhtml2xhtml.xsl
>> transformation the scripts are gone (eaten up).
>> When the page is called using the lenya.usecase GET parameter, the
>> pipeline usecase/usecase.xmap is called and the scripts are
>> inserted correctly.
>> I am interested in your comments / thoughts about this
>
> just a shot in the dark: could it be that the dojo scripts are
> added to the body rather than the head?
It does not look like it - when I remove the xhtml2xhtml.xsl
transformation step from usecasedocument/sitemap.xmap, the dojo
scripts are in the head.
>
> anyways, the current cforms module is a bit messy - it combines
> infrastructure code for cforms with an example doctype, and that is
> not a good idea. cforms support should be a generic module, and
> then there should be an extra resource type module that uses the
> generic one.
I thought I'd use the usecasedocument module as it is done in the
contactform module. What I like about it is, that cocoon.xconf only
has to be patched once for the usecase (no need for samples etc.).
And such a usecasedocument can be moved in the site structure like
any other resource type.
But the usecasedocument module sitemap unfortunately eats up the dojo
scripts...
Thanks, Jörn!
Jürgen
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Joern Nettingsmeier <ne...@folkwang-hochschule.de>.
Jürgen Ragaller wrote:
>
> Am Sep 17, 2007 um 20:43 schrieb Jürgen Ragaller:
>
>>
>> The next thing to find out is how to get the dojo javascript stuff and
>> cocoon form css in the html head...
>>
>
> Here is what I found out about the above problem:
>
> In usecasedocument/sitemap.xmap the transformation
> forms-samples-styling.xsl inserts the dojo scripts but after the
> xhtml2xhtml.xsl transformation the scripts are gone (eaten up).
>
> When the page is called using the lenya.usecase GET parameter, the
> pipeline usecase/usecase.xmap is called and the scripts are inserted
> correctly.
>
> I am interested in your comments / thoughts about this
just a shot in the dark: could it be that the dojo scripts are added to
the body rather than the head?
anyways, the current cforms module is a bit messy - it combines
infrastructure code for cforms with an example doctype, and that is not
a good idea. cforms support should be a generic module, and then there
should be an extra resource type module that uses the generic one.
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
Kurt is up in Heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Joern Nettingsmeier <ne...@folkwang-hochschule.de>.
Jürgen Ragaller wrote:
> Am Sep 20, 2007 um 22:59 schrieb Bob Harner:
>>>
>>
>> To prevent <script src="..."></script> from collapsing to <script />,
>> one normally just adds a space character entity:
>>
>> <script src="..."> </script>
>>
>>
>
> The dojo cform scripts are inserted by a style sheet I do not plan to
> override myself - so in my case that method is not possible.
ah, yes, iirc these stylesheets come from cocoon, so we can't easily add
hacks :(
the firefox crowd really needs to fix this...
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
Kurt is up in Heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Jürgen Ragaller <ra...@null-oder-eins.ch>.
Am Sep 20, 2007 um 22:59 schrieb Bob Harner:
>>
>
> To prevent <script src="..."></script> from collapsing to <script />,
> one normally just adds a space character entity:
>
> <script src="..."> </script>
>
>
The dojo cform scripts are inserted by a style sheet I do not plan to
override myself - so in my case that method is not possible.
Jürgen
Re: [2.0] - cform question
Posted by Bob Harner <bo...@gmail.com>.
On 9/20/07, Jürgen Ragaller <ra...@null-oder-eins.ch> wrote:
> Hi Jörn
>
>
> Am Sep 20, 2007 um 13:03 schrieb Joern Nettingsmeier:
>
> > Jürgen Ragaller wrote:
> >> Am 18.09.2007 um 14:38 schrieb Jürgen Ragaller:
> >>>
> >>> Now the last tiny problem to solve (for now...) is to avoid the
> >>> collapsing of script tags... (right now dojo complains with a
> >>> javascript alert box, that _editor_url is not set - a followup
> >>> error of the partial script tag collapsing).
> >>>
> >> I accidentially had the prettyprinting transformation in my
> >> sitemap (very handy for checking the code but sometimes
> >> dangerous...).
> >> yeah - finally this thing is working - hurray!
> >
> > out of curiousity: how exactly did prettyprinting cause you trouble?
> > it should be fixed so that it doesn't eat javascript sections...
> >
>
> Empty tags are collapsed:
>
> e.g.:
>
> <script src="..." ></script> collapses to <script /> (this was the
> case with the dojo script imports in the head section)
> <textarea></textarea> collapses to <textarea />
>
> The collapsed version is correct xhtml but for instance <script />
> let's firefox go crazy
To prevent <script src="..."></script> from collapsing to <script />,
one normally just adds a space character entity:
<script src="..."> </script>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Jürgen Ragaller <ra...@null-oder-eins.ch>.
Am 21.09.2007 um 15:18 schrieb Jörn Nettingsmeier:
>
> oh yeah, i know about that issue.
> however, strictly speaking it's not a prettyprinting issue - the
> collapsing is done by the XSLT processor, it's not caused by the
> prettyprinting stylesheet.
> so i wonder why it should work when you disable prettyprinting.
I just checked again - i can switch the collapsing on/off by enabling/
disabling the prettyprinting transformation step in our publications
sitemap.
Jürgen
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Richard Frovarp <Ri...@sendit.nodak.edu>.
Jürgen Ragaller wrote:
> Hi Jörn
>
>
> Am Sep 20, 2007 um 13:03 schrieb Joern Nettingsmeier:
>
>> Jürgen Ragaller wrote:
>>> Am 18.09.2007 um 14:38 schrieb Jürgen Ragaller:
>>>>
>>>> Now the last tiny problem to solve (for now...) is to avoid the
>>>> collapsing of script tags... (right now dojo complains with a
>>>> javascript alert box, that _editor_url is not set - a followup
>>>> error of the partial script tag collapsing).
>>>>
>>> I accidentially had the prettyprinting transformation in my sitemap
>>> (very handy for checking the code but sometimes dangerous...).
>>> yeah - finally this thing is working - hurray!
>>
>> out of curiousity: how exactly did prettyprinting cause you trouble?
>> it should be fixed so that it doesn't eat javascript sections...
>>
>
> Empty tags are collapsed:
>
> e.g.:
>
> <script src="..." ></script> collapses to <script /> (this was the
> case with the dojo script imports in the head section)
> <textarea></textarea> collapses to <textarea />
>
> The collapsed version is correct xhtml but for instance <script />
> let's firefox go crazy
>
>
> Jürgen
>
Actually it isn't correct XHTML and it isn't a Firefox bug. It's a bug
in XHTML. From my understanding of XML these two are equivalent:
<foo></foo> and <foo/>. However, they aren't necessarily equivalent in
XHTML. Since XHTML is supposed to be XML, this doesn't track. From
http://www.w3.org/TR/xhtml1/#h-4.3:
"All elements other than those declared in the DTD as EMPTY must have an
end tag. Elements that are declared in the DTD as EMPTY can have an end
tag or can use empty element shorthand"
And from the strict DTD we see that script is not declared as empty.
<!-- script statements, which may include CDATA sections -->
<!ELEMENT script (#PCDATA)>
<!ATTLIST script
id ID #IMPLIED
charset %Charset; #IMPLIED
type %ContentType; #REQUIRED
src %URI; #IMPLIED
defer (defer) #IMPLIED
xml:space (preserve) #FIXED 'preserve'
>
But hr is:
<!--=================== Horizontal Rule
==================================-->
<!ELEMENT hr EMPTY>
<!ATTLIST hr
%attrs;
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Jürgen Ragaller wrote:
> Hi Jörn
>
>
> Am Sep 20, 2007 um 13:03 schrieb Joern Nettingsmeier:
>
>> Jürgen Ragaller wrote:
>>> Am 18.09.2007 um 14:38 schrieb Jürgen Ragaller:
>>>>
>>>> Now the last tiny problem to solve (for now...) is to avoid the
>>>> collapsing of script tags... (right now dojo complains with a
>>>> javascript alert box, that _editor_url is not set - a followup error
>>>> of the partial script tag collapsing).
>>>>
>>> I accidentially had the prettyprinting transformation in my sitemap
>>> (very handy for checking the code but sometimes dangerous...).
>>> yeah - finally this thing is working - hurray!
>>
>> out of curiousity: how exactly did prettyprinting cause you trouble?
>> it should be fixed so that it doesn't eat javascript sections...
>>
>
> Empty tags are collapsed:
>
> e.g.:
>
> <script src="..." ></script> collapses to <script /> (this was the case
> with the dojo script imports in the head section)
> <textarea></textarea> collapses to <textarea />
>
> The collapsed version is correct xhtml but for instance <script /> let's
> firefox go crazy
oh yeah, i know about that issue.
however, strictly speaking it's not a prettyprinting issue - the
collapsing is done by the XSLT processor, it's not caused by the
prettyprinting stylesheet.
so i wonder why it should work when you disable prettyprinting. i'm
using <script> </script> to hack around this issue, which is
transformation-safe...
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Jürgen Ragaller <ra...@null-oder-eins.ch>.
Hi Jörn
Am Sep 20, 2007 um 13:03 schrieb Joern Nettingsmeier:
> Jürgen Ragaller wrote:
>> Am 18.09.2007 um 14:38 schrieb Jürgen Ragaller:
>>>
>>> Now the last tiny problem to solve (for now...) is to avoid the
>>> collapsing of script tags... (right now dojo complains with a
>>> javascript alert box, that _editor_url is not set - a followup
>>> error of the partial script tag collapsing).
>>>
>> I accidentially had the prettyprinting transformation in my
>> sitemap (very handy for checking the code but sometimes
>> dangerous...).
>> yeah - finally this thing is working - hurray!
>
> out of curiousity: how exactly did prettyprinting cause you trouble?
> it should be fixed so that it doesn't eat javascript sections...
>
Empty tags are collapsed:
e.g.:
<script src="..." ></script> collapses to <script /> (this was the
case with the dojo script imports in the head section)
<textarea></textarea> collapses to <textarea />
The collapsed version is correct xhtml but for instance <script />
let's firefox go crazy
Jürgen
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Joern Nettingsmeier <ne...@folkwang-hochschule.de>.
Jürgen Ragaller wrote:
>
> Am 18.09.2007 um 14:38 schrieb Jürgen Ragaller:
>
>
>>
>> Now the last tiny problem to solve (for now...) is to avoid the
>> collapsing of script tags... (right now dojo complains with a
>> javascript alert box, that _editor_url is not set - a followup error
>> of the partial script tag collapsing).
>>
>
> I accidentially had the prettyprinting transformation in my sitemap
> (very handy for checking the code but sometimes dangerous...).
>
> yeah - finally this thing is working - hurray!
out of curiousity: how exactly did prettyprinting cause you trouble?
it should be fixed so that it doesn't eat javascript sections...
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
Kurt is up in Heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Jürgen Ragaller <ra...@null-oder-eins.ch>.
Am 18.09.2007 um 14:38 schrieb Jürgen Ragaller:
>
> Now the last tiny problem to solve (for now...) is to avoid the
> collapsing of script tags... (right now dojo complains with a
> javascript alert box, that _editor_url is not set - a followup
> error of the partial script tag collapsing).
>
I accidentially had the prettyprinting transformation in my sitemap
(very handy for checking the code but sometimes dangerous...).
yeah - finally this thing is working - hurray!
Jürgen
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Jürgen Ragaller <ra...@null-oder-eins.ch>.
Am 18.09.2007 um 10:10 schrieb Thorsten Scherler:
> On Tue, 2007-09-18 at 09:47 +0200, Jürgen Ragaller wrote:
>> Am 18.09.2007 um 08:30 schrieb Thorsten Scherler:
>>
>>> On Mon, 2007-09-17 at 22:38 +0200, Jürgen Ragaller wrote:
>>>> Am Sep 17, 2007 um 20:43 schrieb Jürgen Ragaller:
>>>>
>>>>>
>>>>> The next thing to find out is how to get the dojo javascript stuff
>>>>> and cocoon form css in the html head...
>>>>>
>>>>
>>>> Here is what I found out about the above problem:
>>>>
>>>> In usecasedocument/sitemap.xmap the transformation forms-samples-
>>>> styling.xsl inserts the dojo scripts but after the xhtml2xhtml.xsl
>>>> transformation the scripts are gone (eaten up).
>>>>
>>>> When the page is called using the lenya.usecase GET parameter, the
>>>> pipeline usecase/usecase.xmap is called and the scripts are
>>>> inserted
>>>> correctly.
>>>
>>> So we must find out which code in the usecase.xmap is responsible
>>> for
>>> the correct behavior and fix the eat up.
>>
>> It is not usecase/usecase.xmap causing the trouble.
>
> Yeah, I understood that this code is working.
sorry - misunderstood you...
>
>>
>> I wanted to get a cform in a usecasedocument.
>>
>> Here is what I did:
>>
>> The «usecase document» was created using the following get
>> parameters:
>> usecase=myusecase.event&lenya.usecase=usecasedocument.create
>> (as it is done in contactform)
>>
>> When it is called (using it't normal url e.g. form.html), the
>> following
>> sitemap is handles the cform:
>> usecasedocument/sitemap.xmap (that sitemap eats up the dojo scripts)
>>
>> The reason I took that approach is, that I need to have the form
>> rendered
>> as a lenya document and I got inspiration von contactform.
>>
>>
>
> nice.
>
>
> In fallback://lenya/modules/xhtml/xslt/xhtml2xhtml.xsl we eat the
> head:
>
> <xsl:template match="/xhtml:html">
> <html>
> <body>
> <div id="body">
> <xsl:if test="$rendertype = 'edit'">
> <xsl:attribute
> name="bxe_xpath">/xhtml:html/xhtml:body</xsl:attribute>
> </xsl:if>
> <xsl:apply-templates select="xhtml:body/node()"/>
> </div>
> </body>
> </html>
> </xsl:template>
>
> try something like:
> <xsl:template match="/xhtml:html">
> <html>
> + <head>
> + <xsl:apply-templates select="xhtml:head/node()"/>
> + </head>
> <body>
> <div id="body">
> <xsl:if test="$rendertype = 'edit'">
> <xsl:attribute
> name="bxe_xpath">/xhtml:html/xhtml:body</xsl:attribute>
> </xsl:if>
> <xsl:apply-templates select="xhtml:body/node()"/>
> </div>
> </body>
> </html>
> </xsl:template>
Thanks Thorsten - I had just compared page2xhtml and xhtml2xhtml and
also found the spot you described.
Would that piece of code cause any harm to other transformations or
could it be added to the trunk - WDYT?
Now the last tiny problem to solve (for now...) is to avoid the
collapsing of script tags... (right now dojo complains with a
javascript alert box, that _editor_url is not set - a followup error
of the partial script tag collapsing).
Jürgen
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Tue, 2007-09-18 at 09:47 +0200, Jürgen Ragaller wrote:
> Am 18.09.2007 um 08:30 schrieb Thorsten Scherler:
>
> > On Mon, 2007-09-17 at 22:38 +0200, Jürgen Ragaller wrote:
> >> Am Sep 17, 2007 um 20:43 schrieb Jürgen Ragaller:
> >>
> >>>
> >>> The next thing to find out is how to get the dojo javascript stuff
> >>> and cocoon form css in the html head...
> >>>
> >>
> >> Here is what I found out about the above problem:
> >>
> >> In usecasedocument/sitemap.xmap the transformation forms-samples-
> >> styling.xsl inserts the dojo scripts but after the xhtml2xhtml.xsl
> >> transformation the scripts are gone (eaten up).
> >>
> >> When the page is called using the lenya.usecase GET parameter, the
> >> pipeline usecase/usecase.xmap is called and the scripts are inserted
> >> correctly.
> >
> > So we must find out which code in the usecase.xmap is responsible for
> > the correct behavior and fix the eat up.
>
> It is not usecase/usecase.xmap causing the trouble.
Yeah, I understood that this code is working.
>
> I wanted to get a cform in a usecasedocument.
>
> Here is what I did:
>
> The «usecase document» was created using the following get parameters:
> usecase=myusecase.event&lenya.usecase=usecasedocument.create
> (as it is done in contactform)
>
> When it is called (using it't normal url e.g. form.html), the following
> sitemap is handles the cform:
> usecasedocument/sitemap.xmap (that sitemap eats up the dojo scripts)
>
> The reason I took that approach is, that I need to have the form
> rendered
> as a lenya document and I got inspiration von contactform.
>
>
nice.
In fallback://lenya/modules/xhtml/xslt/xhtml2xhtml.xsl we eat the head:
<xsl:template match="/xhtml:html">
<html>
<body>
<div id="body">
<xsl:if test="$rendertype = 'edit'">
<xsl:attribute
name="bxe_xpath">/xhtml:html/xhtml:body</xsl:attribute>
</xsl:if>
<xsl:apply-templates select="xhtml:body/node()"/>
</div>
</body>
</html>
</xsl:template>
try something like:
<xsl:template match="/xhtml:html">
<html>
+ <head>
+ <xsl:apply-templates select="xhtml:head/node()"/>
+ </head>
<body>
<div id="body">
<xsl:if test="$rendertype = 'edit'">
<xsl:attribute
name="bxe_xpath">/xhtml:html/xhtml:body</xsl:attribute>
</xsl:if>
<xsl:apply-templates select="xhtml:body/node()"/>
</div>
</body>
</html>
</xsl:template>
HTH
salu2
> >
> > I guess we just need to add a xsl:template to match custom "pass on"
> > code.
> >
> > Can you point out the difference since it has been a while when I last
> > played with cforms.
>
> See above
>
> Please let me know if I'm approaching things the wrong way...
> The goal is to have a cform for a complex user contact form.
>
>
> Thanks, Thorsten
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
> For additional commands, e-mail: user-help@lenya.apache.org
>
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Jürgen Ragaller <ra...@null-oder-eins.ch>.
Am 18.09.2007 um 08:30 schrieb Thorsten Scherler:
> On Mon, 2007-09-17 at 22:38 +0200, Jürgen Ragaller wrote:
>> Am Sep 17, 2007 um 20:43 schrieb Jürgen Ragaller:
>>
>>>
>>> The next thing to find out is how to get the dojo javascript stuff
>>> and cocoon form css in the html head...
>>>
>>
>> Here is what I found out about the above problem:
>>
>> In usecasedocument/sitemap.xmap the transformation forms-samples-
>> styling.xsl inserts the dojo scripts but after the xhtml2xhtml.xsl
>> transformation the scripts are gone (eaten up).
>>
>> When the page is called using the lenya.usecase GET parameter, the
>> pipeline usecase/usecase.xmap is called and the scripts are inserted
>> correctly.
>
> So we must find out which code in the usecase.xmap is responsible for
> the correct behavior and fix the eat up.
It is not usecase/usecase.xmap causing the trouble.
I wanted to get a cform in a usecasedocument.
Here is what I did:
The «usecase document» was created using the following get parameters:
usecase=myusecase.event&lenya.usecase=usecasedocument.create
(as it is done in contactform)
When it is called (using it't normal url e.g. form.html), the following
sitemap is handles the cform:
usecasedocument/sitemap.xmap (that sitemap eats up the dojo scripts)
The reason I took that approach is, that I need to have the form
rendered
as a lenya document and I got inspiration von contactform.
>
> I guess we just need to add a xsl:template to match custom "pass on"
> code.
>
> Can you point out the difference since it has been a while when I last
> played with cforms.
See above
Please let me know if I'm approaching things the wrong way...
The goal is to have a cform for a complex user contact form.
Thanks, Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Mon, 2007-09-17 at 22:38 +0200, Jürgen Ragaller wrote:
> Am Sep 17, 2007 um 20:43 schrieb Jürgen Ragaller:
>
> >
> > The next thing to find out is how to get the dojo javascript stuff
> > and cocoon form css in the html head...
> >
>
> Here is what I found out about the above problem:
>
> In usecasedocument/sitemap.xmap the transformation forms-samples-
> styling.xsl inserts the dojo scripts but after the xhtml2xhtml.xsl
> transformation the scripts are gone (eaten up).
>
> When the page is called using the lenya.usecase GET parameter, the
> pipeline usecase/usecase.xmap is called and the scripts are inserted
> correctly.
So we must find out which code in the usecase.xmap is responsible for
the correct behavior and fix the eat up.
I guess we just need to add a xsl:template to match custom "pass on"
code.
Can you point out the difference since it has been a while when I last
played with cforms.
salu2
>
> I am interested in your comments / thoughts about this
>
> Good night.
> Jürgen
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
> For additional commands, e-mail: user-help@lenya.apache.org
>
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Jürgen Ragaller <ra...@null-oder-eins.ch>.
Am Sep 17, 2007 um 20:43 schrieb Jürgen Ragaller:
>
> The next thing to find out is how to get the dojo javascript stuff
> and cocoon form css in the html head...
>
Here is what I found out about the above problem:
In usecasedocument/sitemap.xmap the transformation forms-samples-
styling.xsl inserts the dojo scripts but after the xhtml2xhtml.xsl
transformation the scripts are gone (eaten up).
When the page is called using the lenya.usecase GET parameter, the
pipeline usecase/usecase.xmap is called and the scripts are inserted
correctly.
I am interested in your comments / thoughts about this
Good night.
Jürgen
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: [2.0] - cform question
Posted by Jürgen Ragaller <ra...@null-oder-eins.ch>.
Am Sep 16, 2007 um 22:13 schrieb Jürgen Ragaller:
>
>
> SocketListener0-9 WARN flow.manager - WK: Continuation
> (3b8d0b332d766e4e6b3e64805668713879690665) lookup for wrong
> interpreter. Bound to: file:///Users/jurgenragaller/lenya2src/
> modules/usecasedocument/sitemap.xmap, looked up for: file:///Users/
> jurgenragaller/lenya2/src/modules-core/usecase/usecase.xmap
> SocketListener0-9 ERROR sitemap.handled-errors - The continuation
> ID 3b8d0b332d766e4e6b3e64805668713879690665 is invalid.
> org.apache.cocoon.components.flow.InvalidContinuationException: The
> continuation ID 3b8d0b332d766e4e6b3e64805668713879690665 is invalid.
>
>
> Any help in interpreting the above behaviour is very appreciated -
> I've been digging in the dark for a while now...
>
>
I found the problem - I had a hidden field with a lenya.usecase name
- obviously that leads to a confusion when a usecasedocument is
called ;-))
The next thing to find out is how to get the dojo javascript stuff
and cocoon form css in the html head...
Jürgen
Re: [2.0] - cform question
Posted by Jürgen Ragaller <ra...@null-oder-eins.ch>.
Am Sep 13, 2007 um 15:51 schrieb Andreas Hartmann:
> Jürgen Ragaller schrieb:
>> Hi
>>
>>
>> I have to implement a rather complex contact form in lenya.
>> It would be nice to benefit from the cocoon cform features
>> (validation,
>> i18n, flow, etc.).
>>
>> The modules I looked at for inspiration were cforms (using cforms
>> for a
>> resource-type/usecase) and contactform (using jx/java without a
>> cform).
>>
>> I'm a still a bit confused here
>> - The cforms module has a custom Flowscript featuring a
>> customLoopFlow
>> and a customSubmitFlow
>>
>> Is it a customSubmitFlow I have to write in my case (and reqister the
>> form Definition / Binding / View there)?
>
> No idea, I guess Thorsten knows more.
> Thorsten, is there already some documentation available about this
> feature?
>
>> In the usecase framework docu I read that «Some special complex
>> usecases
>> might require a custom flowscript, in this case you can't use this
>> framework». The customSubmitFlow mechanism seems to be an option to
>> write a custom flow for a 2.0 usecase - or do I walk in the wrong
>> direction?
>
> The comment in the docs is older than the CForms module. Thorsten
> enhanced the usecase framework to allow custom flowscripts.
>
>> Thanks a lot for hints about the best practise to write a contact
>> form
>> module using a cform (if possible)!
>
> Plain CForms are certainly a good start, I have no idea if the CForms
> module is designed for this kind of application. Maybe Thorsten can
> tell
> you more.
>
>
Thanks a lot, Andreas
I managed to setup a cform, writing a customLoopFlow - the validation
is working.
But the working cform has the design of the login screen (no tabs
menu etc.).
To get the cform displayed inside a lenya page envelope I created a
usecase document
using the uri:
usecase=mymodulename.event&lenya.usecase=usecasedocument.create
(as it is done in the contactform module).
This results in a correctly displayed life area lenya page with the
cform inside,
but when I now submit the form I get an error message that the
continuation ID is invalid.
In my custom flow script I basically copied the LoopFlow from
usecase.js and just
added a form definition.
The log after a form submit is somewhat interesting:
SocketListener0-9 WARN flow.manager - WK: Continuation
(3b8d0b332d766e4e6b3e64805668713879690665) lookup for wrong
interpreter. Bound to: file:///Users/jurgenragaller/lenya2src/modules/
usecasedocument/sitemap.xmap, looked up for: file:///Users/
jurgenragaller/lenya2/src/modules-core/usecase/usecase.xmap
SocketListener0-9 ERROR sitemap.handled-errors - The continuation ID
3b8d0b332d766e4e6b3e64805668713879690665 is invalid.
org.apache.cocoon.components.flow.InvalidContinuationException: The
continuation ID 3b8d0b332d766e4e6b3e64805668713879690665 is invalid.
Any help in interpreting the above behaviour is very appreciated -
I've been digging in the dark for a while now...
Jürgen
Re: [2.0] - cform question
Posted by Andreas Hartmann <an...@apache.org>.
Jürgen Ragaller schrieb:
> Hi
>
>
> I have to implement a rather complex contact form in lenya.
> It would be nice to benefit from the cocoon cform features (validation,
> i18n, flow, etc.).
>
> The modules I looked at for inspiration were cforms (using cforms for a
> resource-type/usecase) and contactform (using jx/java without a cform).
>
> I'm a still a bit confused here
> - The cforms module has a custom Flowscript featuring a customLoopFlow
> and a customSubmitFlow
>
> Is it a customSubmitFlow I have to write in my case (and reqister the
> form Definition / Binding / View there)?
No idea, I guess Thorsten knows more.
Thorsten, is there already some documentation available about this feature?
> In the usecase framework docu I read that «Some special complex usecases
> might require a custom flowscript, in this case you can't use this
> framework». The customSubmitFlow mechanism seems to be an option to
> write a custom flow for a 2.0 usecase - or do I walk in the wrong
> direction?
The comment in the docs is older than the CForms module. Thorsten
enhanced the usecase framework to allow custom flowscripts.
> Thanks a lot for hints about the best practise to write a contact form
> module using a cform (if possible)!
Plain CForms are certainly a good start, I have no idea if the CForms
module is designed for this kind of application. Maybe Thorsten can tell
you more.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org