Re: CForms and Portlets - making form ids dynamic

[Carsten Ziegeler]

Sylvain Wallez schrieb:
> Carsten Ziegeler wrote:
>> While cforms is excellent for developing form based applications, it has
>> some (minor) problems if Cocoon is used in a portal environment, being
>> it the Cocoon portal or Cocoon used as a JSR 168 portlet in a different
>> portal container.
>> One of the problems is the uniqueness of ids in the resulting html: each
>> form and input field gets an id based on it's definition in the model.
>> While this works perfectly in a standalone environment this might lead
>> to problems with portals: the portlet may be displayed more than once or
>> the generated ids might interfere with ids generated by other portlets.
>> Therefore a portal usually provides kind of a namespace for each
>> portlet. Fortunately, CForms based applications can make use of such
>> namespaces if you set the id of the form to this namespace. This will
>> then lead to unique ids as the id of the form is prefixed to each input
>> field (the mechanism is in fact more general).
>> The only drawback is that you have to specify this id in the model. And
>> this means that the model is dynamic as each portlet instance must have
>> an own model as each instance must have a different id for the form.
>> This works but of course the form model is never cached.
>>
>> To make cforms more portal friendly I suggest to extend the form
>> creating a little bit by:
>> - adding a createInstance(String formId) method to the FormDefinition
>> - adding createForm(source, String formId) methods to the FormManager
>> - adding a Form(formDefinition, formId) method to form.js
>>
>> WDYT? Or is there a better solution?
>>   
> 
> What about simply adding Form.setId(String formId)?
> 
Yes, that was my first thought as well - but I was wondering if it's a
good idea to "always"
allow to change the id. So I thought that if the id is dynamic, it
should be part of the constructor - therefore the above changes.

But of course just adding setId() works fine as well.

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

[jira] Created: (COCOON-1815) CopySourceAction generate NPE

[JIRA]

CopySourceAction generate NPE
-

 Key: COCOON-1815
 URL: http://issues.apache.org/jira/browse/COCOON-1815
 Project: Cocoon
Type: Bug
  Components: * Cocoon Core  
Versions: 2.1.8
Reporter: Frédéric Glorieux
Priority: Minor




In some circumstances, with internal sources (cocoon:/), 
org/apache/cocoon/acting/copySource.java 

copy-source action generate NPE in Console (nothing seems broken)

Source objects needs to be released
Code may be shorter with usage of excalibur SourceUtil to copy sources

try {
org.apache.excalibur.source.SourceUtil.SourceUtil.copy(src, dest);
} finally {
resolver.release(src);
resolver.release(dest);
}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Questions on cleaning up trunk

[Reinhard Poetz]

Andreas asked in http://issues.apache.org/jira/browse/COCOON-1802 a couple of 
questions. I will try to answer them but please add your comments in the case of 
a different opinion. Changes now are easy, after Wednesday (not Thursday as I 
wrote in my previous mails) when Andreas and I will actually do it they are much 
more difficult:


* Agree on a naming convention for artifact ID suffixes (singular vs. plural): 
e.g. *-mocks, *-impl, *-sample


fine for me.

* What happens with the following dirs within cocoon trunk: lib, misc, src, 
tools?

lib: remove it
misc: goes into trunk/common
src:
# confpatch/remove it - replaced by Maven build
# deprecated/   remove it - things deprecated in 2.1.x are not necessary
in trunk, right?
# osgi-servlet/ remove it - replaced by blocks-fw-osgi-impl
# resources/no idea   - if nobody speaks up till Wednesday, we will
remove them
# samples/  remove it - old or duplicates
# schema/   remove it - outdated
# test/ remove it - Anteater tests: in branch we have a working
httpunit environment. needs to be ported

* Why are databases and xmldb in directory blocks as well as inCocoon trunk?

probably the person who moved them forgot to delete them. Jean-Baptist, wasn't 
it you who did the move? If yes, can we delete them in /cocoon/blocks?


* What happens with scratchpad? Still needed?

yes unfortunatly there is some valuable stuff there, e.g. the caching source

* What's the right version for cocoon-core dependencies: 2.2.0-SNAPSHOT or 
2.2-SNAPSHOT?


2.2.0-SNAPSHOT - we should use the 3-digits pattern IMO

* How should the 'mocks' directory be mapped to the new directory structure?
  - Solution 1: Map to cocoon--mocks/src/main/java (separate artifact)
  - Solution 2: Map to cocoon--impl/src/mock/java (not a standard Maven 
way I think - currently used for the JSP block)
  - Solution 3: Include them in cocoon-mocks/src/mock/java (possibly prefered, 
since it already exists?)
  - Solution 4: May have to be mapped manually (see 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=114277568815707&w=2)


If mocks are specific for a particular block, we should put the classes into a 
separate module. How do we express the dependency so that it compiles with the 
mocks but runs with the implementation?


* Add 'name' tag to each POM in a consistent way:
  - parent POM: 
  - impl POM:  Implementation
  - sample POM:  Samples
  - mock POM:  Mocks

agreed

* Copy/move status.xml
  - There are some inconsistencies for the current new blocks
  - Some are located in the parent block, some in the impl block
  - Where should they be located?
  - May there be more than one? e.g. for impl, sample, ...

Put status.xml into the impl module as for them we will create the 
documentation.


Here some more files that need to be moved:

# CREDITS.txt - Where do we need them? For the distribution?
For now I'd put them into the trunk/commons directory
Thinking more about this, I propose to configure
the assembly plugin for commons so that we can
build distribution packages from there.
# DESKTOP.INI - remains where it is
# INSTALL.txt - move to trunk/commons
# KEYS- move to trunk/commons
# LICENSE.txt - move to trunk/commons
# NOTICE.txt  - move to trunk/commons
# README.blocksmode.txt - remove it (outdated)
# README.m10n.txt - leave it where it is
# README.osgi.txt - remove it (outdated)
# README.txt - move to trunk/commons
# TO-SYNC-FROM-BRANCH.txt - leave it
# announcement.xml - move to trunk/commons

Anything else that needs to be considered by Andreas and me?


--
Reinhard Pötz   Independent Consultant, Trainer & (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc






___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [vote] Simone Gianni as a new Cocoon committer

[Sylvain Wallez]

Niclas Hedhman wrote:
> On Friday 24 March 2006 18:19, Sylvain Wallez wrote:
>   
>> Hi all,
>>
>> It's spring time, new committers are blossoming! I'd like to propose
>> Simone Gianni for Cocoon committership.
>>
>> Simone has contributed interesting additions and bug fixes to CForms
>> that show a very good understanding of this stuff, and is participating
>> more and more to discussions. It's time for him to be able to commit his
>> patches himself!
>>
>> Please cast your votes.
>> 
>
>
> Has anyone directed Simone to get the paperwork in order?
>   

Uh, not even a "real" committer and already taking care of the
paperwork? Thanks Niclas!

Sylvain

-- 
Sylvain Wallez
http://bluxte.net
Apache Software Foundation Member

Re: [vote] Simone Gianni as a new Cocoon committer

[Guido Casper]

Sylvain Wallez schrieb:

I'd like to propose Simone Gianni for Cocoon committership.


+1

Guido

Re: [vote] Niclas Hedhman as a new Cocoon committer

[Guido Casper]

Daniel Fagerstrom schrieb:

I'd like to propose Niclas Hedhman as a new Cocoon committer.


+1

Guido

Re: [vote] Simone Gianni as a new Cocoon committer

[Niclas Hedhman]

On Friday 24 March 2006 18:19, Sylvain Wallez wrote:
> Hi all,
>
> It's spring time, new committers are blossoming! I'd like to propose
> Simone Gianni for Cocoon committership.
>
> Simone has contributed interesting additions and bug fixes to CForms
> that show a very good understanding of this stuff, and is participating
> more and more to discussions. It's time for him to be able to commit his
> patches himself!
>
> Please cast your votes.


Has anyone directed Simone to get the paperwork in order?

Simone; You need to download, read, understand and if approve, sign and fax or 
"postal mail" the Contributor License Agreement to the ASF Secretary. Fax 
number and address is on the form.
http://www.apache.org/licenses/#clas

You should also read;
http://www.apache.org/dev/new-committers-guide.html
http://www.apache.org/dev/committers.html

Once that is done, the Cocoon PMC needs to forward an account creation request 
to [EMAIL PROTECTED];

Details for that is found at; http://www.apache.org/dev/pmc.html#newcommitter

Finally, the Cocoon PMC Chair (Sylvain) is expected to update the 
authorization for the subversion repository.


Cheers
Niclas.

Re: Deployment into a monolithic Cocoon web app

[Antonio Gallardo]

Thanks Reinhard! It simply works again. :-)

[jira] Closed: (COCOON-1814) Deprecated method o.a.c.environment.Environment.getOutputStream() still used internally

[Antonio Gallardo (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1814?page=all ]
 
Antonio Gallardo closed COCOON-1814:


Resolution: Fixed

Thanks for the patch! It was applied with minor changes. Please cross check and 
reopen the bug if needed.

> Deprecated method o.a.c.environment.Environment.getOutputStream() still used 
> internally
> ---
>
>  Key: COCOON-1814
>  URL: http://issues.apache.org/jira/browse/COCOON-1814
>  Project: Cocoon
> Type: Bug
>   Components: * Cocoon Core
> Versions: 2.1.8, 2.1.9-dev (current SVN)
> Reporter: Mark Lundquist
> Assignee: Antonio Gallardo
>  Fix For: 2.1.9-dev (current SVN)
>  Attachments: patch
>
> class o.a.c.environment.wrapper.EnvironmentWrapper deprecated the 
> parameterless getOutputStream, but still uses it internally, resulting in 
> deprecation log spam.
> I made a patch, and then when I checked to see if 2.2-dev is affected I saw 
> that it has been fixed there.  Here's the patch for 2.1.9-dev anyway.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (COCOON-1814) Deprecated method o.a.c.environment.Environment.getOutputStream() still used internally

[Antonio Gallardo (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1814?page=all ]

Antonio Gallardo updated COCOON-1814:
-

Summary: Deprecated method o.a.c.environment.Environment.getOutputStream() 
still used internally  (was: Deprecated method 
oa.c.environment.Environment.getOutputStream() still used internally)

> Deprecated method o.a.c.environment.Environment.getOutputStream() still used 
> internally
> ---
>
>  Key: COCOON-1814
>  URL: http://issues.apache.org/jira/browse/COCOON-1814
>  Project: Cocoon
> Type: Bug
>   Components: * Cocoon Core
> Versions: 2.1.8, 2.1.9-dev (current SVN)
> Reporter: Mark Lundquist
> Assignee: Antonio Gallardo
>  Fix For: 2.1.9-dev (current SVN)
>  Attachments: patch
>
> class o.a.c.environment.wrapper.EnvironmentWrapper deprecated the 
> parameterless getOutputStream, but still uses it internally, resulting in 
> deprecation log spam.
> I made a patch, and then when I checked to see if 2.2-dev is affected I saw 
> that it has been fixed there.  Here's the patch for 2.1.9-dev anyway.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (COCOON-1814) Deprecated method oa.c.environment.Environment.getOutputStream() still used internally

[Antonio Gallardo (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1814?page=all ]

Antonio Gallardo updated COCOON-1814:
-

Summary: Deprecated method 
oa.c.environment.Environment.getOutputStream() still used internally  (was: 
Deprecated form of getOutputStream() still used internally)
Fix Version: 2.1.9-dev (current SVN)
Description: 
class o.a.c.environment.wrapper.EnvironmentWrapper deprecated the parameterless 
getOutputStream, but still uses it internally, resulting in deprecation log 
spam.

I made a patch, and then when I checked to see if 2.2-dev is affected I saw 
that it has been fixed there.  Here's the patch for 2.1.9-dev anyway.

  was:
class oac.environment.wrapper.EnvironmentWrapper deprecated the parameterless 
getOutputStream, but still uses it internally, resulting in deprecation log 
spam.

I made a patch, and then when I checked to see if 2.2-dev is affected I saw 
that it has been fixed there.  Here's the patch for 2.1.9-dev anyway.


> Deprecated method oa.c.environment.Environment.getOutputStream() still used 
> internally
> --
>
>  Key: COCOON-1814
>  URL: http://issues.apache.org/jira/browse/COCOON-1814
>  Project: Cocoon
> Type: Bug
>   Components: * Cocoon Core
> Versions: 2.1.8, 2.1.9-dev (current SVN)
> Reporter: Mark Lundquist
> Assignee: Antonio Gallardo
>  Fix For: 2.1.9-dev (current SVN)
>  Attachments: patch
>
> class o.a.c.environment.wrapper.EnvironmentWrapper deprecated the 
> parameterless getOutputStream, but still uses it internally, resulting in 
> deprecation log spam.
> I made a patch, and then when I checked to see if 2.2-dev is affected I saw 
> that it has been fixed there.  Here's the patch for 2.1.9-dev anyway.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Updating the Website

[David Crossley]

Jean-Baptiste Quenot wrote:
> Hello,
> 
> Is it possible to propagate the update of this page from Daisy to
> the website:
> http://cocoon.apache.org/community/members.html
> 
> Or please tell me where to edit it.

The source is not in Daisy.

http://wiki.apache.org/cocoon/CocoonWebsiteUpdate

If you don't want to do the Forrest part, then just
edit the source, then ask here. Someone else will
generate the site.

> BTW what remains to be done to switch from the old site to the new
> one?

Would you explain what you mean. AFAIK, there is
no plan to do anything with the top-level site.

-David

[jira] Updated: (COCOON-1812) Javaflow and Ajax when sending two forms one after eachother

[Simone Gianni (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1812?page=all ]

Simone Gianni updated COCOON-1812:
--

Attachment: javaflow-ajax.diff

Patch for javaflow ajax continue

> Javaflow and Ajax when sending two forms one after eachother
> 
>
>  Key: COCOON-1812
>  URL: http://issues.apache.org/jira/browse/COCOON-1812
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Forms, Blocks: Java Flow
> Versions: 2.1.9-dev (current SVN)
> Reporter: Simone Gianni
> Priority: Critical
>  Attachments: javaflow-ajax.diff
>
> In javaflow, if I try to send an ajax form and then send another ajax form I 
> obtain a NPE originating from JXMacroHelper.
> For example :
>   FormInstance fi = new FormInstance("myform.def.xml");
>   fi.show("mypipe");
>   fi = new FormInstance("myotherform.def.xml");
>   fi.show("myotherpipe");
> I receive an NPE originating from JXMacroHelper:162  while showing the second 
> forms.
> After investigations i noticed that the second form was displayed following 
> the ajax behaviour, while this second form is new and should not be "ajaxed". 
> This causes the updatedWidgets list to be null (both in form and in 
> JXMacroHelper) and thus the NPE.
> Sniffing the http traffic showed me that while in javascript the submission 
> of the first form causes a  and a new non-ajax request from the 
> browser, while with javaflow this does not happen.
> Seems like the lines from 176 to 201 of 
> /cocoon-2.1.X/src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript/Form.js
>  were not ported to the javaflow FormInstance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (COCOON-1812) Javaflow and Ajax when sending two forms one after eachother

[Simone Gianni (JIRA)]

[ 
http://issues.apache.org/jira/browse/COCOON-1812?page=comments#action_12371926 
] 

Simone Gianni commented on COCOON-1812:
---

Fixed this, now it works this way :

- The form is sent
- Once the form is complete and correct, a bu:continue is sent
... Please note that i ported the js code, but had to use redirector.setStatus 
to avoid CallFunctionNode exception
- The continuation is suspended, and will never regain control.
- The client calls the next continuation, sending a cocoon-ajax-continue=true
- This reenters the show method, so it first checks if cocoon-ajax-continue is 
present and in that case simply exits the loop.

> Javaflow and Ajax when sending two forms one after eachother
> 
>
>  Key: COCOON-1812
>  URL: http://issues.apache.org/jira/browse/COCOON-1812
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Forms, Blocks: Java Flow
> Versions: 2.1.9-dev (current SVN)
> Reporter: Simone Gianni
> Priority: Critical

>
> In javaflow, if I try to send an ajax form and then send another ajax form I 
> obtain a NPE originating from JXMacroHelper.
> For example :
>   FormInstance fi = new FormInstance("myform.def.xml");
>   fi.show("mypipe");
>   fi = new FormInstance("myotherform.def.xml");
>   fi.show("myotherpipe");
> I receive an NPE originating from JXMacroHelper:162  while showing the second 
> forms.
> After investigations i noticed that the second form was displayed following 
> the ajax behaviour, while this second form is new and should not be "ajaxed". 
> This causes the updatedWidgets list to be null (both in form and in 
> JXMacroHelper) and thus the NPE.
> Sniffing the http traffic showed me that while in javascript the submission 
> of the first form causes a  and a new non-ajax request from the 
> browser, while with javaflow this does not happen.
> Seems like the lines from 176 to 201 of 
> /cocoon-2.1.X/src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript/Form.js
>  were not ported to the javaflow FormInstance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Assigned: (COCOON-1814) Deprecated form of getOutputStream() still used internally

[Antonio Gallardo (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1814?page=all ]

Antonio Gallardo reassigned COCOON-1814:


Assign To: Antonio Gallardo

> Deprecated form of getOutputStream() still used internally
> --
>
>  Key: COCOON-1814
>  URL: http://issues.apache.org/jira/browse/COCOON-1814
>  Project: Cocoon
> Type: Bug
>   Components: * Cocoon Core
> Versions: 2.1.8, 2.1.9-dev (current SVN)
> Reporter: Mark Lundquist
> Assignee: Antonio Gallardo
>  Attachments: patch
>
> class oac.environment.wrapper.EnvironmentWrapper deprecated the parameterless 
> getOutputStream, but still uses it internally, resulting in deprecation log 
> spam.
> I made a patch, and then when I checked to see if 2.2-dev is affected I saw 
> that it has been fixed there.  Here's the patch for 2.1.9-dev anyway.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [vote] Simone Gianni as a new Cocoon committer

[Joerg Heinicke]

On 24.03.2006 11:19, Sylvain Wallez wrote:


I'd like to propose Simone Gianni for Cocoon committership.


+1

Jörg

[jira] Commented: (COCOON-1804) Javascript FOM_SCOPE issue when using Java as the flow engine - ReferenceError: "cocoon" is not defined

[Simone Gianni (JIRA)]

[ 
http://issues.apache.org/jira/browse/COCOON-1804?page=comments#action_12371909 
] 

Simone Gianni commented on COCOON-1804:
---

here is the java class : 
src/blocks/forms/java/org/apache/cocoon/forms/samples/CustomBirthDateValidator.java
here is the form model : src/blocks/forms/samples/forms/form2_model.xml


> Javascript FOM_SCOPE issue when using Java as the flow engine - 
> ReferenceError: "cocoon" is not defined
> ---
>
>  Key: COCOON-1804
>  URL: http://issues.apache.org/jira/browse/COCOON-1804
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Java Flow
> Versions: 2.1.8
> Reporter: Andrew Madu
> Priority: Blocker

>
> I have created a  java flow class which does the following:
> //Load in validation file
> FormInstance form = new FormInstance("forms/login.xml");
> My login map (snippet) is as follows:
> Login.xml:
> 
> 
> var success = true;
> var newUserReg = new Packages.test.User();
> var username = widget.lookupWidget("username");
> var password = widget.lookupWidget("password");
>
> try {
> 
> var checkUserTest = newUserReg.getUser(username.value, 
> password.value);
> 
> if (checkUserTest != null) {
> cocoon.session.setAttribute("user", checkUserTest);
> success = true;
> }else{
> username.setValidationError(new 
> Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
> password.setValidationError(new 
> Packages.org.apache.cocoon.forms.validation.ValidationError("The password, 
> username combination does not exist. Please enter another one.", false));
> success = false;
> }
> } catch (e) {
> username.setValidationError(new 
> Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
> password.setValidationError(new 
> Packages.org.apache.cocoon.forms.validation.ValidationError("e.", false));
> success = false;
> }
> return success;
> 
> 
> I am getting an error message when the line 
> 'cocoon.session.setAttribute("user", checkUserTest)' is hit.:
> ReferenceError: "cocoon" is not defined
> What is the issue here, can I create a session object from within form 
> validation/javascript in another way?
> Andrew

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (COCOON-1814) Deprecated form of getOutputStream() still used internally

[Mark Lundquist (JIRA)]

Deprecated form of getOutputStream() still used internally
--

 Key: COCOON-1814
 URL: http://issues.apache.org/jira/browse/COCOON-1814
 Project: Cocoon
Type: Bug
  Components: * Cocoon Core  
Versions: 2.1.8, 2.1.9-dev (current SVN)
Reporter: Mark Lundquist
 Attachments: patch

class oac.environment.wrapper.EnvironmentWrapper deprecated the parameterless 
getOutputStream, but still uses it internally, resulting in deprecation log 
spam.

I made a patch, and then when I checked to see if 2.2-dev is affected I saw 
that it has been fixed there.  Here's the patch for 2.1.9-dev anyway.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: CForms and Portlets - making form ids dynamic

[Sylvain Wallez]

Carsten Ziegeler wrote:
> While cforms is excellent for developing form based applications, it has
> some (minor) problems if Cocoon is used in a portal environment, being
> it the Cocoon portal or Cocoon used as a JSR 168 portlet in a different
> portal container.
> One of the problems is the uniqueness of ids in the resulting html: each
> form and input field gets an id based on it's definition in the model.
> While this works perfectly in a standalone environment this might lead
> to problems with portals: the portlet may be displayed more than once or
> the generated ids might interfere with ids generated by other portlets.
> Therefore a portal usually provides kind of a namespace for each
> portlet. Fortunately, CForms based applications can make use of such
> namespaces if you set the id of the form to this namespace. This will
> then lead to unique ids as the id of the form is prefixed to each input
> field (the mechanism is in fact more general).
> The only drawback is that you have to specify this id in the model. And
> this means that the model is dynamic as each portlet instance must have
> an own model as each instance must have a different id for the form.
> This works but of course the form model is never cached.
>
> To make cforms more portal friendly I suggest to extend the form
> creating a little bit by:
> - adding a createInstance(String formId) method to the FormDefinition
> - adding createForm(source, String formId) methods to the FormManager
> - adding a Form(formDefinition, formId) method to form.js
>
> WDYT? Or is there a better solution?
>   

What about simply adding Form.setId(String formId)?

Sylvain

-- 
Sylvain Wallez
http://bluxte.net
Apache Software Foundation Member

Re: Deployment into a monolithic Cocoon web app

[Reinhard Poetz]

Carsten Ziegeler wrote:

Reinhard Poetz wrote:


0. checkout complete trunk and
  $ mvn clean install -Dmaven.test.skip=true

  Call this as long as you get "BUILD SUCCESSFUL".

1. go to cocoon-webapp
  $ mvn cocoo:deploy
  $ mvn jetty6:run

2. point your browser to http://localhost:/ or 
http://localhost:/apps/cocoon-deployer-plugin-demo/test


Please report back if it works for you too.



Works for me. Nice!

There seems to be a problem with the deployer: if you invoke the
deployer twice (without cleaning up in between), then you run into
deployment exception (sitemap already exists).


The bug should be fixed now in SVN and the exception is only thrown if a file is 
written twice within the same run.


Two more things:

 - Carsten, I tried to deploy the session-fw but didn't succeeded because
   the xconf files aren't correct. Could you have a look at it?
   (the dependency on session-fw-samples is commented in the pom.xml ATM)

 - Currently the deployer deploys into "target/cocoon-webapp/apps". This
   is fine for building a package but it's a problem at development time
   as every change would require a redeployment.

   Any ideas?

--
Reinhard Pötz   Independent Consultant, Trainer & (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc






___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

CForms and Portlets - making form ids dynamic

[Carsten Ziegeler]

While cforms is excellent for developing form based applications, it has
some (minor) problems if Cocoon is used in a portal environment, being
it the Cocoon portal or Cocoon used as a JSR 168 portlet in a different
portal container.
One of the problems is the uniqueness of ids in the resulting html: each
form and input field gets an id based on it's definition in the model.
While this works perfectly in a standalone environment this might lead
to problems with portals: the portlet may be displayed more than once or
the generated ids might interfere with ids generated by other portlets.
Therefore a portal usually provides kind of a namespace for each
portlet. Fortunately, CForms based applications can make use of such
namespaces if you set the id of the form to this namespace. This will
then lead to unique ids as the id of the form is prefixed to each input
field (the mechanism is in fact more general).
The only drawback is that you have to specify this id in the model. And
this means that the model is dynamic as each portlet instance must have
an own model as each instance must have a different id for the form.
This works but of course the form model is never cached.

To make cforms more portal friendly I suggest to extend the form
creating a little bit by:
- adding a createInstance(String formId) method to the FormDefinition
- adding createForm(source, String formId) methods to the FormManager
- adding a Form(formDefinition, formId) method to form.js

WDYT? Or is there a better solution?

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