Re: [Forms] Bug in Ajax when changing widget state?
>> Hi people, >> still trying to push CForms to its limits ;) I found what might be a >> bug in the Ajax implementations. I have an event handler that switches > the state of a widget from ACTIVE to INVISIBLE and vice-versa. When not > using Ajax, everything works fine, but when ajax="true" the widget > appears and disappears as expected, but its label stays forever hidden! > Two points to note here: > 1. the widget state is initially INVISIBLE > 2. the widget is laid out in a group using > Can anyone else confirm this? > Ugo -- > Ugo Cei > Tech Blog: http://agylen.com/ > Open Source Zone: http://oszone.org/ > Wine & Food Blog: http://www.divinocibo.it/ Hi People, I found the message above that it's an old message, but that still being an issue on CForms. I found that the label field is not visible again because we only sent the ... for the input field but for the label we don't have anything similar. When we show the form that initially have a field invisible and the field it's on a ... we sent a placeholder for the field and this generate this: and for example for a field "field2" (that is because the XSLT, now we only generate the SAX's event only for the input, the label tag is generate because the XSLT) Now, when we got visible the field, the it's just only for the field, we don't manage in anyway the label tag. This is similar if the field it's initially visible, when we got invisible the input field is gone, but the label still there because we don't manage the label on the ajax update. This is similar too when we use the ... tag, this generate the raw text of the label it does not generate the html tag and i think we should generate and we should add ad "id" attribute to the tag, so some how we can manage the label tag on a ajax replace. Now, I'm not sure how we can manage the label, we don't generate the label on the SAX events, we generate the label on the XSLT, the thing is how can we know that the ajax update should contains the label replacement? we can generate always and the ajax update try to find the label, but don't generate any error if we don't find, but looks like a hack. any thoughts ? Cheers, -- Carlos Chávez
[jira] Commented: (COCOON-2074) Build ignores custom applications
[
https://issues.apache.org/jira/browse/COCOON-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554964
]
solprovider commented on COCOON-2074:
-
Vadim Gritsenko suggested on the Dev ML to use s in the "copy all" and
remove overwrite=true. Using 'overwrite' is bad design, doubles the work of the
build script, and adds work and time to the "do-nothing" build.
> Build ignores custom applications
> -
>
> Key: COCOON-2074
> URL: https://issues.apache.org/jira/browse/COCOON-2074
> Project: Cocoon
> Issue Type: Improvement
> Components: - Build System: Ant
>Affects Versions: 2.1.10
>Reporter: solprovider
>Priority: Minor
> Fix For: 2.1.11-dev (Current SVN)
>
>
> The build process carefully adds each of the standard files in the webapp
> directory. New applications are not included in the build process. The
> improvement copies the entire directory. I did not notice any files needing
> to be excluded; any such files could be excluded from the fileset.
> webapp-build.xml
> CURRENT CODE:
> filtering="on"/>
> tofile="${build.webapp}/not-found.xml" filtering="on"/>
> filtering="on"/>
> tofile="${build.webapp}/sitemap.xmap"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> REPLACE WITH:
>
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (COCOON-2074) Build ignores custom applications
On Dec 29, 2007, at 4:10 PM, solprovider (JIRA) wrote: [ https://issues.apache.org/jira/browse/COCOON-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel #action_12554955 ] solprovider commented on COCOON-2074: - This version copies the directory with filtering="off", then overwrites the files requiring filtering="on" FILE: webapp-build.xml REPLACE WITH: You should add s here and remove overwrite=true below. Using 'overwrite' here indicates bad tone: it doubles amount of work done by the build script, and adds work (and increases the time) to the "do- nothing" build. Vadim overwrite="true">
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
On 12/29/07, Ralph Goers <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > Creating the jira posted to the Cocoon Dev ML in June. Nobody > > commented. Should we consider that as no interest or no objections? I > > did not receive notification that nobody looked at the jira. What is > > the proper channel for more review? > This list. If you want to advocate for something you can't just sit back > and wait. This is true of any open source project. > > Carsten has reverted the commit and objects to improving creation of > > applications because some method exists that is better than the > > obvious one (that this commit tried to improve). The Cocoon-2.1 > > documentation has a hole where the application creation instructions > > belong. Should this discussion continue? > Yes, unless you feel it isn't worth pursuing. No one is saying they > don't agree with your objective. They just don't agree with the > particular implementation. > Ralph On 12/29/07, Grzegorz Kossakowski <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] pisze: > > We needed a new 2.1 because at least one very annoying bug was > > patched. When releasing 2.1.11 was first discussed, someone mentioned > > making this the final release as most of the Cocoon devs are working > > on 2.2. I hope you are correct that development of Cocoon-2.1 has not > > ended. I like Cocoon-2.1 and have several patches to contribute. > > This patch was to make application creation even easier. Cocoon-2.2 > > has progressed in a different direction and requires much more > > configuration. > It was me who wanted to kill 2.1.x branch but I was pointed out immediately > that in OS world there > is no way to kill something. As long as there is a community interest 2.1.x > branch will be live. You > may noticed that some people has expressed such an interest. > > I understand your motivation to have all your patches included in upcoming > release but this one is > really controversial so you must understand it may generate tensions. > > When it comes to reviewing. I think it's fair to say that if there is no > response to your JIRA > report/mail on dev within 2-3 weeks it's wise to send another e-mail to the > dev list reminding > people of your affair. I have done this several times in the past. > Grzegorz Kossakowski Having commit rights meant I did not need to sit back and wait. The jira gave the project notice of my intentions; nobody objected. Controversy requires interest. Nobody cared about this. I would have committed this two weeks after the jira if I had time. Committing generated more review, but none was constructive. Fixing the implementation required much less thought than this thread. I reopened the jira and added an implementation that solves the ant-copy-filtering concerns: http://issues.apache.org/jira/browse/COCOON-2074 Can this be included in 2.1.11? Killing an OS project is easy -- just create a new version that interests developers and chases away users. The old versions die from lack of development. The new version dies from lack of use. A demonstration is in progress. solprovider
[jira] Commented: (COCOON-2074) Build ignores custom applications
[
https://issues.apache.org/jira/browse/COCOON-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554955
]
solprovider commented on COCOON-2074:
-
This version copies the directory with filtering="off", then overwrites the
files requiring filtering="on"
FILE: webapp-build.xml
REPLACE WITH:
> Build ignores custom applications
> -
>
> Key: COCOON-2074
> URL: https://issues.apache.org/jira/browse/COCOON-2074
> Project: Cocoon
> Issue Type: Improvement
> Components: - Build System: Ant
>Affects Versions: 2.1.10
>Reporter: solprovider
>Priority: Minor
> Fix For: 2.1.11-dev (Current SVN)
>
>
> The build process carefully adds each of the standard files in the webapp
> directory. New applications are not included in the build process. The
> improvement copies the entire directory. I did not notice any files needing
> to be excluded; any such files could be excluded from the fileset.
> webapp-build.xml
> CURRENT CODE:
> filtering="on"/>
> tofile="${build.webapp}/not-found.xml" filtering="on"/>
> filtering="on"/>
> tofile="${build.webapp}/sitemap.xmap"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> REPLACE WITH:
>
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (COCOON-2074) Build ignores custom applications
[
https://issues.apache.org/jira/browse/COCOON-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
solprovider reopened COCOON-2074:
-
The commit was reverted due to concerns about filtering damaging binary files.
> Build ignores custom applications
> -
>
> Key: COCOON-2074
> URL: https://issues.apache.org/jira/browse/COCOON-2074
> Project: Cocoon
> Issue Type: Improvement
> Components: - Build System: Ant
>Affects Versions: 2.1.10
>Reporter: solprovider
>Priority: Minor
> Fix For: 2.1.11-dev (Current SVN)
>
>
> The build process carefully adds each of the standard files in the webapp
> directory. New applications are not included in the build process. The
> improvement copies the entire directory. I did not notice any files needing
> to be excluded; any such files could be excluded from the fileset.
> webapp-build.xml
> CURRENT CODE:
> filtering="on"/>
> tofile="${build.webapp}/not-found.xml" filtering="on"/>
> filtering="on"/>
> tofile="${build.webapp}/sitemap.xmap"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> REPLACE WITH:
>
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1831) Passing parameters to sub calls
[
https://issues.apache.org/jira/browse/COCOON-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554947
]
Reinhard Poetz commented on COCOON-1831:
Thanks for the update on your patch. I had already been wondering how your code
could work correctly with only one getNames() implementation ;-)
I've applied the patch locally and it looks good so far. I will commit it some
time next week. Then I will work on setting up a test infrastructure so that we
can test all this really important code thoroughly.
> Passing parameters to sub calls
> ---
>
> Key: COCOON-1831
> URL: https://issues.apache.org/jira/browse/COCOON-1831
> Project: Cocoon
> Issue Type: New Feature
> Components: - Servlet service framework
>Reporter: Reinhard Poetz
>Assignee: Reinhard Poetz
> Attachments: BlockCallHttpServletRequest.patch,
> cocoon-servlet-service-impl.patch, cocoon-servlet-service-impl.patch
>
>
> When a servlet service request is created, parameters from the parent request
> are ignored. This means that the sub request is performed as a fresh and
> clean new call. This would avoid any possible side-effects, but is very
> inconvenient in practice because you don't even know the request header
> parameters from the original (external) request. Additionally you can only
> pass information which is part of the returned stream, which is e.g. a
> blocker to use the servlet protocol together with the control flow
> implementations. Those make use of special request parameters to transport
> the model ("bizdata") to the view layer.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
[EMAIL PROTECTED] pisze: > > We needed a new 2.1 because at least one very annoying bug was > patched. When releasing 2.1.11 was first discussed, someone mentioned > making this the final release as most of the Cocoon devs are working > on 2.2. I hope you are correct that development of Cocoon-2.1 has not > ended. I like Cocoon-2.1 and have several patches to contribute. > This patch was to make application creation even easier. Cocoon-2.2 > has progressed in a different direction and requires much more > configuration. It was me who wanted to kill 2.1.x branch but I was pointed out immediately that in OS world there is no way to kill something. As long as there is a community interest 2.1.x branch will be live. You may noticed that some people has expressed such an interest. I understand your motivation to have all your patches included in upcomming release but this one is really controversial so you must understand it may generate tensions. When it comes to reviewing. I think it's fair to say that if there is no response to your JIRA report/mail on dev within 2-3 weeks it's wise to send another e-mail to the dev list reminding people of your affair. I have done this several times in the past. -- Grzegorz Kossakowski
