You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Zdenek Sochor (JIRA)" <de...@myfaces.apache.org> on 2006/12/12 09:22:21 UTC
[jira] Created: (TOMAHAWK-819) Re-enabled autogeneration of
components code, fixed bug in commandButton/commandLink, adding several
valueBindings to components
Re-enabled autogeneration of components code, fixed bug in commandButton/commandLink, adding several valueBindings to components
--------------------------------------------------------------------------------------------------------------------------------
Key: TOMAHAWK-819
URL: http://issues.apache.org/jira/browse/TOMAHAWK-819
Project: MyFaces Tomahawk
Issue Type: Improvement
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Zdenek Sochor
Priority: Critical
Attachments: build-tools.patch
I wanted to expand functionality of role management in components, (TOMAHAWK-489), but i ended in re-enabling autogeneration of code.
This should simplify adding of properties and gettter/setter with save/restore state of components INCLUDING fixing several components which
didn't take EL values for several properties, for which it should have.
Autogeneration is based on old maven build tools.
Currently (in patch), autogeneration for TOMAHAWK components is w/o error (at least in components with XML definition),
BUT autogenerated Myfaces CORE components breaks several examples (MYFACES-1509)
- this can be fixed by reverting of myfaces-api changes after generation.
After reverting core, autogenerated Tomahawk classes can be used in final snapshot.
I added support for role management of enable/disableOnUserRole:
It supports 3 logical functions:
- logical AND (user has to be in ALL roles specified)
- logical OR (user has to be in ONE of roles specified),
this is default mode (and only 1 currently supported in Tomahawk)
- logical NOT (user MUST NOT be in any roles specified)
If none/attribute not specified or other String used, it defaults to OR function.
This extension to functionality takes in account 'disabled' and 'rendered' attributes:
- disabled="true" take precedence in case of 'enabledOnUserRole'
- 'rendered' value is taken in account AFTER evaluating roles
Examples:
<t:commandButton value="value" enabledOnUserRole="role1,role2" roleSelectionMode="not" disabled="false" />
[to be enabled, user MUST NOT be in both role1 AND role2]
<t:commandButton value="value" enabledOnUserRole="role1,role2" roleSelectionMode="not" disabled="true" />
[always disabled]
<t:commandButton value="value" visibleOnUserRole="role1,role2,role3" roleSelectionMode="and" />
[to be visible, user MUST BE in all roles - role1, role2 AND role3]
<t:commandButton value="value" visibleOnUserRole="role1,role2" roleSelectionMode="and" rendered="false"/>
[never rendered]
<t:commandButton value="value" enabledOnUserRole="role1,role2,role3" roleSelectionMode="or" />
EQUALS
<t:commandButton value="value" enabledOnUserRole="role1,role2,role3"/>
[to be enabled, user MUST BE in one or more roles from list (role1, role2, role3)]
-------------------------------------------------------------
Hidden bug in commandButton/commandLink - fixed
-------------------------------------------------------------
Note on bug:
EnabledOnUserRole is currently never used in HtmlCommandButton (tomahawk 1.1.5 in svn)
-- i addded support for it (method isDisabled())
--
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: (TOMAHAWK-819) Re-enabled autogeneration of
components code, fixed bug in commandButton/commandLink, adding several
valueBindings to components
Posted by "Zdenek Sochor (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TOMAHAWK-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Zdenek Sochor updated TOMAHAWK-819:
-----------------------------------
Resolution: Invalid
Status: Resolved (was: Patch Available)
Cancelling issue
> Re-enabled autogeneration of components code, fixed bug in commandButton/commandLink, adding several valueBindings to components
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: TOMAHAWK-819
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-819
> Project: MyFaces Tomahawk
> Issue Type: Improvement
> Affects Versions: 1.1.5-SNAPSHOT
> Reporter: Zdenek Sochor
> Priority: Trivial
> Attachments: build-tools(no roleSelectionMode).patch, build-tools.patch, tomahawk(no roleSelectionMode).patch, tomahawk.patch
>
>
> I wanted to expand functionality of role management in components, (TOMAHAWK-489), but i ended in re-enabling autogeneration of code.
> This should simplify adding of properties and gettter/setter with save/restore state of components INCLUDING fixing several components which
> didn't take EL values for several properties, for which it should have.
> Autogeneration is based on old maven build tools.
> Currently (in patch), autogeneration for TOMAHAWK components is w/o error (at least in components with XML definition),
> BUT autogenerated Myfaces CORE components breaks several examples (MYFACES-1509)
> - this can be fixed by reverting of myfaces-api changes after generation.
> After reverting core, autogenerated Tomahawk classes can be used in final snapshot.
> I added support for role management of enable/disableOnUserRole:
> It supports 3 logical functions:
> - logical AND (user has to be in ALL roles specified)
> - logical OR (user has to be in ONE of roles specified),
> this is default mode (and only 1 currently supported in Tomahawk)
> - logical NOT (user MUST NOT be in any roles specified)
> If none/attribute not specified or other String used, it defaults to OR function.
> This extension to functionality takes in account 'disabled' and 'rendered' attributes:
> - disabled="true" take precedence in case of 'enabledOnUserRole'
> - 'rendered' value is taken in account AFTER evaluating roles
> Examples:
> <t:commandButton value="value" enabledOnUserRole="role1,role2" roleSelectionMode="not" disabled="false" />
> [to be enabled, user MUST NOT be in both role1 AND role2]
> <t:commandButton value="value" enabledOnUserRole="role1,role2" roleSelectionMode="not" disabled="true" />
> [always disabled]
> <t:commandButton value="value" visibleOnUserRole="role1,role2,role3" roleSelectionMode="and" />
> [to be visible, user MUST BE in all roles - role1, role2 AND role3]
> <t:commandButton value="value" visibleOnUserRole="role1,role2" roleSelectionMode="and" rendered="false"/>
> [never rendered]
> <t:commandButton value="value" enabledOnUserRole="role1,role2,role3" roleSelectionMode="or" />
> EQUALS
> <t:commandButton value="value" enabledOnUserRole="role1,role2,role3"/>
> [to be enabled, user MUST BE in one or more roles from list (role1, role2, role3)]
> -------------------------------------------------------------
> Hidden bug in commandButton/commandLink - fixed
> -------------------------------------------------------------
> Note on bug:
> EnabledOnUserRole is currently never used in HtmlCommandButton (tomahawk 1.1.5 in svn)
> -- i addded support for it (method isDisabled())
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-819) Re-enabled autogeneration of
components code, fixed bug in commandButton/commandLink, adding several
valueBindings to components
Posted by "Zdenek Sochor (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/TOMAHAWK-819?page=comments#action_12457633 ]
Zdenek Sochor commented on TOMAHAWK-819:
----------------------------------------
SecurityContext is what i missed in Tomahawk, but simple replacing enabled/visibleOnUserRole with SecurityContext would break old applications.
Basically, my addition does the same thing as SecurityContext, but binds to other components' properties.
SecurityContext depends on security stored in FacesContext (which is used in my addition in the end too), BUT there is NO method how to issue different modes of authority roles for different components in the same page (let say to display div tag when user has not required role).
> Re-enabled autogeneration of components code, fixed bug in commandButton/commandLink, adding several valueBindings to components
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: TOMAHAWK-819
> URL: http://issues.apache.org/jira/browse/TOMAHAWK-819
> Project: MyFaces Tomahawk
> Issue Type: Improvement
> Affects Versions: 1.1.5-SNAPSHOT
> Reporter: Zdenek Sochor
> Priority: Critical
> Attachments: build-tools.patch, tomahawk.patch
>
>
> I wanted to expand functionality of role management in components, (TOMAHAWK-489), but i ended in re-enabling autogeneration of code.
> This should simplify adding of properties and gettter/setter with save/restore state of components INCLUDING fixing several components which
> didn't take EL values for several properties, for which it should have.
> Autogeneration is based on old maven build tools.
> Currently (in patch), autogeneration for TOMAHAWK components is w/o error (at least in components with XML definition),
> BUT autogenerated Myfaces CORE components breaks several examples (MYFACES-1509)
> - this can be fixed by reverting of myfaces-api changes after generation.
> After reverting core, autogenerated Tomahawk classes can be used in final snapshot.
> I added support for role management of enable/disableOnUserRole:
> It supports 3 logical functions:
> - logical AND (user has to be in ALL roles specified)
> - logical OR (user has to be in ONE of roles specified),
> this is default mode (and only 1 currently supported in Tomahawk)
> - logical NOT (user MUST NOT be in any roles specified)
> If none/attribute not specified or other String used, it defaults to OR function.
> This extension to functionality takes in account 'disabled' and 'rendered' attributes:
> - disabled="true" take precedence in case of 'enabledOnUserRole'
> - 'rendered' value is taken in account AFTER evaluating roles
> Examples:
> <t:commandButton value="value" enabledOnUserRole="role1,role2" roleSelectionMode="not" disabled="false" />
> [to be enabled, user MUST NOT be in both role1 AND role2]
> <t:commandButton value="value" enabledOnUserRole="role1,role2" roleSelectionMode="not" disabled="true" />
> [always disabled]
> <t:commandButton value="value" visibleOnUserRole="role1,role2,role3" roleSelectionMode="and" />
> [to be visible, user MUST BE in all roles - role1, role2 AND role3]
> <t:commandButton value="value" visibleOnUserRole="role1,role2" roleSelectionMode="and" rendered="false"/>
> [never rendered]
> <t:commandButton value="value" enabledOnUserRole="role1,role2,role3" roleSelectionMode="or" />
> EQUALS
> <t:commandButton value="value" enabledOnUserRole="role1,role2,role3"/>
> [to be enabled, user MUST BE in one or more roles from list (role1, role2, role3)]
> -------------------------------------------------------------
> Hidden bug in commandButton/commandLink - fixed
> -------------------------------------------------------------
> Note on bug:
> EnabledOnUserRole is currently never used in HtmlCommandButton (tomahawk 1.1.5 in svn)
> -- i addded support for it (method isDisabled())
--
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: (TOMAHAWK-819) Re-enabled autogeneration of
components code, fixed bug in commandButton/commandLink, adding several
valueBindings to components
Posted by "Mario Ivankovits (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/TOMAHAWK-819?page=comments#action_12457646 ]
Mario Ivankovits commented on TOMAHAWK-819:
-------------------------------------------
I admit, I've not used it till today, but you'll be able to provide your own SecurityContext implementation, wouldn't it allow you to implement your own needs?
> This is qute other approach to the matter than enabled/visibleOnUserRole, which is based on setting security requirements to single component.
Which roles a component belongs to (if you would like to see it that way) is configured as expression language within the standard component attributes.
say:
<t:div rendered=#{securityContext.ifGranted['rolename']}>
The way how to determine if a user is allowed (or not) is routed through the (or your) security context implementation.
Isn't it sufficient?
> Re-enabled autogeneration of components code, fixed bug in commandButton/commandLink, adding several valueBindings to components
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: TOMAHAWK-819
> URL: http://issues.apache.org/jira/browse/TOMAHAWK-819
> Project: MyFaces Tomahawk
> Issue Type: Improvement
> Affects Versions: 1.1.5-SNAPSHOT
> Reporter: Zdenek Sochor
> Priority: Critical
> Attachments: build-tools.patch, tomahawk.patch
>
>
> I wanted to expand functionality of role management in components, (TOMAHAWK-489), but i ended in re-enabling autogeneration of code.
> This should simplify adding of properties and gettter/setter with save/restore state of components INCLUDING fixing several components which
> didn't take EL values for several properties, for which it should have.
> Autogeneration is based on old maven build tools.
> Currently (in patch), autogeneration for TOMAHAWK components is w/o error (at least in components with XML definition),
> BUT autogenerated Myfaces CORE components breaks several examples (MYFACES-1509)
> - this can be fixed by reverting of myfaces-api changes after generation.
> After reverting core, autogenerated Tomahawk classes can be used in final snapshot.
> I added support for role management of enable/disableOnUserRole:
> It supports 3 logical functions:
> - logical AND (user has to be in ALL roles specified)
> - logical OR (user has to be in ONE of roles specified),
> this is default mode (and only 1 currently supported in Tomahawk)
> - logical NOT (user MUST NOT be in any roles specified)
> If none/attribute not specified or other String used, it defaults to OR function.
> This extension to functionality takes in account 'disabled' and 'rendered' attributes:
> - disabled="true" take precedence in case of 'enabledOnUserRole'
> - 'rendered' value is taken in account AFTER evaluating roles
> Examples:
> <t:commandButton value="value" enabledOnUserRole="role1,role2" roleSelectionMode="not" disabled="false" />
> [to be enabled, user MUST NOT be in both role1 AND role2]
> <t:commandButton value="value" enabledOnUserRole="role1,role2" roleSelectionMode="not" disabled="true" />
> [always disabled]
> <t:commandButton value="value" visibleOnUserRole="role1,role2,role3" roleSelectionMode="and" />
> [to be visible, user MUST BE in all roles - role1, role2 AND role3]
> <t:commandButton value="value" visibleOnUserRole="role1,role2" roleSelectionMode="and" rendered="false"/>
> [never rendered]
> <t:commandButton value="value" enabledOnUserRole="role1,role2,role3" roleSelectionMode="or" />
> EQUALS
> <t:commandButton value="value" enabledOnUserRole="role1,role2,role3"/>
> [to be enabled, user MUST BE in one or more roles from list (role1, role2, role3)]
> -------------------------------------------------------------
> Hidden bug in commandButton/commandLink - fixed
> -------------------------------------------------------------
> Note on bug:
> EnabledOnUserRole is currently never used in HtmlCommandButton (tomahawk 1.1.5 in svn)
> -- i addded support for it (method isDisabled())
--
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: (TOMAHAWK-819) Re-enabled autogeneration of
components code, fixed bug in commandButton/commandLink, adding several
valueBindings to components
Posted by "Mario Ivankovits (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/TOMAHAWK-819?page=comments#action_12457638 ]
Mario Ivankovits commented on TOMAHAWK-819:
-------------------------------------------
We wont remove them from tomahawk without a sufficient dependency period, no worry :-)
> BUT there is NO method how to issue different modes of authority roles for different components in the same page (let say to display div tag when user has not required role).
Hmmm ...... I dont understand.
As far as I know you can simply use the "rendered=#{}" way to determine if a component should be rendered, based on the security el.
> Re-enabled autogeneration of components code, fixed bug in commandButton/commandLink, adding several valueBindings to components
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: TOMAHAWK-819
> URL: http://issues.apache.org/jira/browse/TOMAHAWK-819
> Project: MyFaces Tomahawk
> Issue Type: Improvement
> Affects Versions: 1.1.5-SNAPSHOT
> Reporter: Zdenek Sochor
> Priority: Critical
> Attachments: build-tools.patch, tomahawk.patch
>
>
> I wanted to expand functionality of role management in components, (TOMAHAWK-489), but i ended in re-enabling autogeneration of code.
> This should simplify adding of properties and gettter/setter with save/restore state of components INCLUDING fixing several components which
> didn't take EL values for several properties, for which it should have.
> Autogeneration is based on old maven build tools.
> Currently (in patch), autogeneration for TOMAHAWK components is w/o error (at least in components with XML definition),
> BUT autogenerated Myfaces CORE components breaks several examples (MYFACES-1509)
> - this can be fixed by reverting of myfaces-api changes after generation.
> After reverting core, autogenerated Tomahawk classes can be used in final snapshot.
> I added support for role management of enable/disableOnUserRole:
> It supports 3 logical functions:
> - logical AND (user has to be in ALL roles specified)
> - logical OR (user has to be in ONE of roles specified),
> this is default mode (and only 1 currently supported in Tomahawk)
> - logical NOT (user MUST NOT be in any roles specified)
> If none/attribute not specified or other String used, it defaults to OR function.
> This extension to functionality takes in account 'disabled' and 'rendered' attributes:
> - disabled="true" take precedence in case of 'enabledOnUserRole'
> - 'rendered' value is taken in account AFTER evaluating roles
> Examples:
> <t:commandButton value="value" enabledOnUserRole="role1,role2" roleSelectionMode="not" disabled="false" />
> [to be enabled, user MUST NOT be in both role1 AND role2]
> <t:commandButton value="value" enabledOnUserRole="role1,role2" roleSelectionMode="not" disabled="true" />
> [always disabled]
> <t:commandButton value="value" visibleOnUserRole="role1,role2,role3" roleSelectionMode="and" />
> [to be visible, user MUST BE in all roles - role1, role2 AND role3]
> <t:commandButton value="value" visibleOnUserRole="role1,role2" roleSelectionMode="and" rendered="false"/>
> [never rendered]
> <t:commandButton value="value" enabledOnUserRole="role1,role2,role3" roleSelectionMode="or" />
> EQUALS
> <t:commandButton value="value" enabledOnUserRole="role1,role2,role3"/>
> [to be enabled, user MUST BE in one or more roles from list (role1, role2, role3)]
> -------------------------------------------------------------
> Hidden bug in commandButton/commandLink - fixed
> -------------------------------------------------------------
> Note on bug:
> EnabledOnUserRole is currently never used in HtmlCommandButton (tomahawk 1.1.5 in svn)
> -- i addded support for it (method isDisabled())
--
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: (TOMAHAWK-819) Re-enabled autogeneration of
components code, fixed bug in commandButton/commandLink, adding several
valueBindings to components
Posted by "Mario Ivankovits (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/TOMAHAWK-819?page=comments#action_12457625 ]
Mario Ivankovits commented on TOMAHAWK-819:
-------------------------------------------
Hmmm ... I am not sure what other MyFaces developer think about it, but I think the enableOnUserRole stuff should be replaced by the new org.apache.myfaces.custom.security package [1]?
This allows you to do even more complex stuff by simply using the standard enable="" and disbaled="" properties
Have a look at its wiki [2] for more documentation.
[1] http://myfaces.apache.org/sandbox/xref/org/apache/myfaces/custom/security/package-summary.html
[2] http://wiki.apache.org/myfaces/SecurityContext
> Re-enabled autogeneration of components code, fixed bug in commandButton/commandLink, adding several valueBindings to components
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: TOMAHAWK-819
> URL: http://issues.apache.org/jira/browse/TOMAHAWK-819
> Project: MyFaces Tomahawk
> Issue Type: Improvement
> Affects Versions: 1.1.5-SNAPSHOT
> Reporter: Zdenek Sochor
> Priority: Critical
> Attachments: build-tools.patch, tomahawk.patch
>
>
> I wanted to expand functionality of role management in components, (TOMAHAWK-489), but i ended in re-enabling autogeneration of code.
> This should simplify adding of properties and gettter/setter with save/restore state of components INCLUDING fixing several components which
> didn't take EL values for several properties, for which it should have.
> Autogeneration is based on old maven build tools.
> Currently (in patch), autogeneration for TOMAHAWK components is w/o error (at least in components with XML definition),
> BUT autogenerated Myfaces CORE components breaks several examples (MYFACES-1509)
> - this can be fixed by reverting of myfaces-api changes after generation.
> After reverting core, autogenerated Tomahawk classes can be used in final snapshot.
> I added support for role management of enable/disableOnUserRole:
> It supports 3 logical functions:
> - logical AND (user has to be in ALL roles specified)
> - logical OR (user has to be in ONE of roles specified),
> this is default mode (and only 1 currently supported in Tomahawk)
> - logical NOT (user MUST NOT be in any roles specified)
> If none/attribute not specified or other String used, it defaults to OR function.
> This extension to functionality takes in account 'disabled' and 'rendered' attributes:
> - disabled="true" take precedence in case of 'enabledOnUserRole'
> - 'rendered' value is taken in account AFTER evaluating roles
> Examples:
> <t:commandButton value="value" enabledOnUserRole="role1,role2" roleSelectionMode="not" disabled="false" />
> [to be enabled, user MUST NOT be in both role1 AND role2]
> <t:commandButton value="value" enabledOnUserRole="role1,role2" roleSelectionMode="not" disabled="true" />
> [always disabled]
> <t:commandButton value="value" visibleOnUserRole="role1,role2,role3" roleSelectionMode="and" />
> [to be visible, user MUST BE in all roles - role1, role2 AND role3]
> <t:commandButton value="value" visibleOnUserRole="role1,role2" roleSelectionMode="and" rendered="false"/>
> [never rendered]
> <t:commandButton value="value" enabledOnUserRole="role1,role2,role3" roleSelectionMode="or" />
> EQUALS
> <t:commandButton value="value" enabledOnUserRole="role1,role2,role3"/>
> [to be enabled, user MUST BE in one or more roles from list (role1, role2, role3)]
> -------------------------------------------------------------
> Hidden bug in commandButton/commandLink - fixed
> -------------------------------------------------------------
> Note on bug:
> EnabledOnUserRole is currently never used in HtmlCommandButton (tomahawk 1.1.5 in svn)
> -- i addded support for it (method isDisabled())
--
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: (TOMAHAWK-819) Re-enabled autogeneration of
components code, fixed bug in commandButton/commandLink, adding several
valueBindings to components
Posted by "Cagatay Civici (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TOMAHAWK-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477932 ]
Cagatay Civici commented on TOMAHAWK-819:
-----------------------------------------
I don't think we should integrate new stuff to a feature like securityAttributes that'll be deprecated soon. Also securityContext is simpler to use for page devs;
<t:commandButton value="value" visibleOnUserRole="role1,role2,role3" roleSelectionMode="and" />
<t:commandButton value="value" rendered="#{securityContext.ifAllGranted['role1','role2','role3']}" />
> Re-enabled autogeneration of components code, fixed bug in commandButton/commandLink, adding several valueBindings to components
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: TOMAHAWK-819
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-819
> Project: MyFaces Tomahawk
> Issue Type: Improvement
> Affects Versions: 1.1.5-SNAPSHOT
> Reporter: Zdenek Sochor
> Priority: Critical
> Attachments: build-tools(no roleSelectionMode).patch, build-tools.patch, tomahawk(no roleSelectionMode).patch, tomahawk.patch
>
>
> I wanted to expand functionality of role management in components, (TOMAHAWK-489), but i ended in re-enabling autogeneration of code.
> This should simplify adding of properties and gettter/setter with save/restore state of components INCLUDING fixing several components which
> didn't take EL values for several properties, for which it should have.
> Autogeneration is based on old maven build tools.
> Currently (in patch), autogeneration for TOMAHAWK components is w/o error (at least in components with XML definition),
> BUT autogenerated Myfaces CORE components breaks several examples (MYFACES-1509)
> - this can be fixed by reverting of myfaces-api changes after generation.
> After reverting core, autogenerated Tomahawk classes can be used in final snapshot.
> I added support for role management of enable/disableOnUserRole:
> It supports 3 logical functions:
> - logical AND (user has to be in ALL roles specified)
> - logical OR (user has to be in ONE of roles specified),
> this is default mode (and only 1 currently supported in Tomahawk)
> - logical NOT (user MUST NOT be in any roles specified)
> If none/attribute not specified or other String used, it defaults to OR function.
> This extension to functionality takes in account 'disabled' and 'rendered' attributes:
> - disabled="true" take precedence in case of 'enabledOnUserRole'
> - 'rendered' value is taken in account AFTER evaluating roles
> Examples:
> <t:commandButton value="value" enabledOnUserRole="role1,role2" roleSelectionMode="not" disabled="false" />
> [to be enabled, user MUST NOT be in both role1 AND role2]
> <t:commandButton value="value" enabledOnUserRole="role1,role2" roleSelectionMode="not" disabled="true" />
> [always disabled]
> <t:commandButton value="value" visibleOnUserRole="role1,role2,role3" roleSelectionMode="and" />
> [to be visible, user MUST BE in all roles - role1, role2 AND role3]
> <t:commandButton value="value" visibleOnUserRole="role1,role2" roleSelectionMode="and" rendered="false"/>
> [never rendered]
> <t:commandButton value="value" enabledOnUserRole="role1,role2,role3" roleSelectionMode="or" />
> EQUALS
> <t:commandButton value="value" enabledOnUserRole="role1,role2,role3"/>
> [to be enabled, user MUST BE in one or more roles from list (role1, role2, role3)]
> -------------------------------------------------------------
> Hidden bug in commandButton/commandLink - fixed
> -------------------------------------------------------------
> Note on bug:
> EnabledOnUserRole is currently never used in HtmlCommandButton (tomahawk 1.1.5 in svn)
> -- i addded support for it (method isDisabled())
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-819) Re-enabled autogeneration of
components code, fixed bug in commandButton/commandLink, adding several
valueBindings to components
Posted by "Zdenek Sochor (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/TOMAHAWK-819?page=all ]
Zdenek Sochor updated TOMAHAWK-819:
-----------------------------------
Status: Patch Available (was: Open)
> Re-enabled autogeneration of components code, fixed bug in commandButton/commandLink, adding several valueBindings to components
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: TOMAHAWK-819
> URL: http://issues.apache.org/jira/browse/TOMAHAWK-819
> Project: MyFaces Tomahawk
> Issue Type: Improvement
> Affects Versions: 1.1.5-SNAPSHOT
> Reporter: Zdenek Sochor
> Priority: Critical
> Attachments: build-tools.patch, tomahawk.patch
>
>
> I wanted to expand functionality of role management in components, (TOMAHAWK-489), but i ended in re-enabling autogeneration of code.
> This should simplify adding of properties and gettter/setter with save/restore state of components INCLUDING fixing several components which
> didn't take EL values for several properties, for which it should have.
> Autogeneration is based on old maven build tools.
> Currently (in patch), autogeneration for TOMAHAWK components is w/o error (at least in components with XML definition),
> BUT autogenerated Myfaces CORE components breaks several examples (MYFACES-1509)
> - this can be fixed by reverting of myfaces-api changes after generation.
> After reverting core, autogenerated Tomahawk classes can be used in final snapshot.
> I added support for role management of enable/disableOnUserRole:
> It supports 3 logical functions:
> - logical AND (user has to be in ALL roles specified)
> - logical OR (user has to be in ONE of roles specified),
> this is default mode (and only 1 currently supported in Tomahawk)
> - logical NOT (user MUST NOT be in any roles specified)
> If none/attribute not specified or other String used, it defaults to OR function.
> This extension to functionality takes in account 'disabled' and 'rendered' attributes:
> - disabled="true" take precedence in case of 'enabledOnUserRole'
> - 'rendered' value is taken in account AFTER evaluating roles
> Examples:
> <t:commandButton value="value" enabledOnUserRole="role1,role2" roleSelectionMode="not" disabled="false" />
> [to be enabled, user MUST NOT be in both role1 AND role2]
> <t:commandButton value="value" enabledOnUserRole="role1,role2" roleSelectionMode="not" disabled="true" />
> [always disabled]
> <t:commandButton value="value" visibleOnUserRole="role1,role2,role3" roleSelectionMode="and" />
> [to be visible, user MUST BE in all roles - role1, role2 AND role3]
> <t:commandButton value="value" visibleOnUserRole="role1,role2" roleSelectionMode="and" rendered="false"/>
> [never rendered]
> <t:commandButton value="value" enabledOnUserRole="role1,role2,role3" roleSelectionMode="or" />
> EQUALS
> <t:commandButton value="value" enabledOnUserRole="role1,role2,role3"/>
> [to be enabled, user MUST BE in one or more roles from list (role1, role2, role3)]
> -------------------------------------------------------------
> Hidden bug in commandButton/commandLink - fixed
> -------------------------------------------------------------
> Note on bug:
> EnabledOnUserRole is currently never used in HtmlCommandButton (tomahawk 1.1.5 in svn)
> -- i addded support for it (method isDisabled())
--
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: (TOMAHAWK-819) Re-enabled autogeneration of
components code, fixed bug in commandButton/commandLink, adding several
valueBindings to components
Posted by "Zdenek Sochor (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/TOMAHAWK-819?page=comments#action_12457639 ]
Zdenek Sochor commented on TOMAHAWK-819:
----------------------------------------
Unless i'm mistaken badly
public String getAuthType() {
return FacesContext.getCurrentInstance().getExternalContext().getAuthType();
}
(in SecurityContextImpl.java)
you get only security reference valid for whole application.
This is qute other approach to the matter than enabled/visibleOnUserRole, which is based on setting security requirements to single component.
And if i look further on code for SecurityContext, i see
Btw, is there any (even uncomplete) example to see SecurityContext in action?
> Re-enabled autogeneration of components code, fixed bug in commandButton/commandLink, adding several valueBindings to components
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: TOMAHAWK-819
> URL: http://issues.apache.org/jira/browse/TOMAHAWK-819
> Project: MyFaces Tomahawk
> Issue Type: Improvement
> Affects Versions: 1.1.5-SNAPSHOT
> Reporter: Zdenek Sochor
> Priority: Critical
> Attachments: build-tools.patch, tomahawk.patch
>
>
> I wanted to expand functionality of role management in components, (TOMAHAWK-489), but i ended in re-enabling autogeneration of code.
> This should simplify adding of properties and gettter/setter with save/restore state of components INCLUDING fixing several components which
> didn't take EL values for several properties, for which it should have.
> Autogeneration is based on old maven build tools.
> Currently (in patch), autogeneration for TOMAHAWK components is w/o error (at least in components with XML definition),
> BUT autogenerated Myfaces CORE components breaks several examples (MYFACES-1509)
> - this can be fixed by reverting of myfaces-api changes after generation.
> After reverting core, autogenerated Tomahawk classes can be used in final snapshot.
> I added support for role management of enable/disableOnUserRole:
> It supports 3 logical functions:
> - logical AND (user has to be in ALL roles specified)
> - logical OR (user has to be in ONE of roles specified),
> this is default mode (and only 1 currently supported in Tomahawk)
> - logical NOT (user MUST NOT be in any roles specified)
> If none/attribute not specified or other String used, it defaults to OR function.
> This extension to functionality takes in account 'disabled' and 'rendered' attributes:
> - disabled="true" take precedence in case of 'enabledOnUserRole'
> - 'rendered' value is taken in account AFTER evaluating roles
> Examples:
> <t:commandButton value="value" enabledOnUserRole="role1,role2" roleSelectionMode="not" disabled="false" />
> [to be enabled, user MUST NOT be in both role1 AND role2]
> <t:commandButton value="value" enabledOnUserRole="role1,role2" roleSelectionMode="not" disabled="true" />
> [always disabled]
> <t:commandButton value="value" visibleOnUserRole="role1,role2,role3" roleSelectionMode="and" />
> [to be visible, user MUST BE in all roles - role1, role2 AND role3]
> <t:commandButton value="value" visibleOnUserRole="role1,role2" roleSelectionMode="and" rendered="false"/>
> [never rendered]
> <t:commandButton value="value" enabledOnUserRole="role1,role2,role3" roleSelectionMode="or" />
> EQUALS
> <t:commandButton value="value" enabledOnUserRole="role1,role2,role3"/>
> [to be enabled, user MUST BE in one or more roles from list (role1, role2, role3)]
> -------------------------------------------------------------
> Hidden bug in commandButton/commandLink - fixed
> -------------------------------------------------------------
> Note on bug:
> EnabledOnUserRole is currently never used in HtmlCommandButton (tomahawk 1.1.5 in svn)
> -- i addded support for it (method isDisabled())
--
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