You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Dan Adams (JIRA)" <de...@tapestry.apache.org> on 2007/06/15 15:14:25 UTC
[jira] Created: (TAPESTRY-1579) More flexibility in using
beaneditform
More flexibility in using beaneditform
--------------------------------------
Key: TAPESTRY-1579
URL: https://issues.apache.org/jira/browse/TAPESTRY-1579
Project: Tapestry
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.0.5
Reporter: Dan Adams
We do a lot of work with content management systems and thus use forms a lot. I would really like to use BeanEditForm as it's got a lot of great features but it has a couple limitations that, at this point, means we won't be able to use it.
The first is that it creates it's own form which limits being able to use it in conjunction with more complicated forms. Perhaps add a boolean 'createForm' parameter which defaults to true and indicates whether or not to render a form. Or better still, detect whether the component is rendering in a form and only create one if there is no outer form. Or both and have the behavior default to the latter.
The second is that I have no control over the rendering of the html around the fields. It would be really useful if there was either an override I contribute to or a parameter to provide a renderer or both. If I had that then I could use beaneditform and know that the structure of the fields and labels would be consistent with the rest of the system.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Updated: (TAPESTRY-1579) Allow multiple BeanEditor
components within a form
Posted by "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship updated TAPESTRY-1579:
-------------------------------------------
Summary: Allow multiple BeanEditor components within a form (was: More flexibility in using beaneditform)
> Allow multiple BeanEditor components within a form
> --------------------------------------------------
>
> Key: TAPESTRY-1579
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1579
> Project: Tapestry
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.0.5
> Reporter: Dan Adams
> Assignee: Howard M. Lewis Ship
>
> We do a lot of work with content management systems and thus use forms a lot. I would really like to use BeanEditForm as it's got a lot of great features but it has a couple limitations that, at this point, means we won't be able to use it.
> The first is that it creates it's own form which limits being able to use it in conjunction with more complicated forms. Perhaps add a boolean 'createForm' parameter which defaults to true and indicates whether or not to render a form. Or better still, detect whether the component is rendering in a form and only create one if there is no outer form. Or both and have the behavior default to the latter.
> The second is that I have no control over the rendering of the html around the fields. It would be really useful if there was either an override I contribute to or a parameter to provide a renderer or both. If I had that then I could use beaneditform and know that the structure of the fields and labels would be consistent with the rest of the system.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-1579) More flexibility in using
beaneditform
Posted by "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505238 ]
Howard M. Lewis Ship commented on TAPESTRY-1579:
------------------------------------------------
I totally agree; it's been in the back of my mind to split out BeanEditForm into BeanEditor (very resuable) plus a BeanEditForm wrapper for convenience.
In addition, creating an EditProperty component (as the basis for BeanEditor) would make reuse even easier.
> More flexibility in using beaneditform
> --------------------------------------
>
> Key: TAPESTRY-1579
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1579
> Project: Tapestry
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.0.5
> Reporter: Dan Adams
>
> We do a lot of work with content management systems and thus use forms a lot. I would really like to use BeanEditForm as it's got a lot of great features but it has a couple limitations that, at this point, means we won't be able to use it.
> The first is that it creates it's own form which limits being able to use it in conjunction with more complicated forms. Perhaps add a boolean 'createForm' parameter which defaults to true and indicates whether or not to render a form. Or better still, detect whether the component is rendering in a form and only create one if there is no outer form. Or both and have the behavior default to the latter.
> The second is that I have no control over the rendering of the html around the fields. It would be really useful if there was either an override I contribute to or a parameter to provide a renderer or both. If I had that then I could use beaneditform and know that the structure of the fields and labels would be consistent with the rest of the system.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Closed: (TAPESTRY-1579) Allow multiple BeanEditor components
within a form
Posted by "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship closed TAPESTRY-1579.
------------------------------------------
Resolution: Fixed
Fix Version/s: 5.0.6
Came out Sweet!
> Allow multiple BeanEditor components within a form
> --------------------------------------------------
>
> Key: TAPESTRY-1579
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1579
> Project: Tapestry
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.0.5
> Reporter: Dan Adams
> Assignee: Howard M. Lewis Ship
> Fix For: 5.0.6
>
>
> We do a lot of work with content management systems and thus use forms a lot. I would really like to use BeanEditForm as it's got a lot of great features but it has a couple limitations that, at this point, means we won't be able to use it.
> The first is that it creates it's own form which limits being able to use it in conjunction with more complicated forms. Perhaps add a boolean 'createForm' parameter which defaults to true and indicates whether or not to render a form. Or better still, detect whether the component is rendering in a form and only create one if there is no outer form. Or both and have the behavior default to the latter.
> The second is that I have no control over the rendering of the html around the fields. It would be really useful if there was either an override I contribute to or a parameter to provide a renderer or both. If I had that then I could use beaneditform and know that the structure of the fields and labels would be consistent with the rest of the system.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Assigned: (TAPESTRY-1579) More flexibility in using
beaneditform
Posted by "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship reassigned TAPESTRY-1579:
----------------------------------------------
Assignee: Howard M. Lewis Ship
> More flexibility in using beaneditform
> --------------------------------------
>
> Key: TAPESTRY-1579
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1579
> Project: Tapestry
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.0.5
> Reporter: Dan Adams
> Assignee: Howard M. Lewis Ship
>
> We do a lot of work with content management systems and thus use forms a lot. I would really like to use BeanEditForm as it's got a lot of great features but it has a couple limitations that, at this point, means we won't be able to use it.
> The first is that it creates it's own form which limits being able to use it in conjunction with more complicated forms. Perhaps add a boolean 'createForm' parameter which defaults to true and indicates whether or not to render a form. Or better still, detect whether the component is rendering in a form and only create one if there is no outer form. Or both and have the behavior default to the latter.
> The second is that I have no control over the rendering of the html around the fields. It would be really useful if there was either an override I contribute to or a parameter to provide a renderer or both. If I had that then I could use beaneditform and know that the structure of the fields and labels would be consistent with the rest of the system.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-1579) More flexibility in using
beaneditform
Posted by "Dan Adams (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505224 ]
Dan Adams commented on TAPESTRY-1579:
-------------------------------------
Also, another showstopper is that it renders it's own submit button. I need to be able to use beaneditform and have it just render the fields without a form or submit button and be able to control the html surrounding the fields.
> More flexibility in using beaneditform
> --------------------------------------
>
> Key: TAPESTRY-1579
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1579
> Project: Tapestry
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.0.5
> Reporter: Dan Adams
>
> We do a lot of work with content management systems and thus use forms a lot. I would really like to use BeanEditForm as it's got a lot of great features but it has a couple limitations that, at this point, means we won't be able to use it.
> The first is that it creates it's own form which limits being able to use it in conjunction with more complicated forms. Perhaps add a boolean 'createForm' parameter which defaults to true and indicates whether or not to render a form. Or better still, detect whether the component is rendering in a form and only create one if there is no outer form. Or both and have the behavior default to the latter.
> The second is that I have no control over the rendering of the html around the fields. It would be really useful if there was either an override I contribute to or a parameter to provide a renderer or both. If I had that then I could use beaneditform and know that the structure of the fields and labels would be consistent with the rest of the system.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org