[jira] Created: (TRINIDAD-1056) Chang maven-faces-plugin to stop filtering out metadata

[My Faces - Dev mailing list]

Chang maven-faces-plugin to stop filtering out metadata
--------------------------------------------------------

                 Key: TRINIDAD-1056
                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1056
             Project: MyFaces Trinidad
          Issue Type: New Feature
          Components: Plugins
    Affects Versions: 1.2.7-core, 1.0.7-core
            Reporter: Andrew Robinson
            Assignee: Andrew Robinson


The maven-faces-plugin has two xsl files, transform.xsl and transform12.xsl. These files are used to build the final version of the faces-config.xml. Right now they are implemented to support a certain set of elements in the facet-extension and property-extension.

For example, the XSL code basically says, if there is an <mfp:required/> element under the <property-extension/>, then create a new element called <required/> and apply the templates to its guts.

This is a very inflexible design as for every new mfp:* property that an IDE adds support for, we have to update the XSL files and ship a new version. I would like to change this so that all mfp:* elements are automatically stripped of the namespace and copied over without filtering. I don't see any value in filtering these out in the plug-in.

Right now I'd like to add <mfp:hidden/> so that if component B extends component A, but does not want to make one of the properties a part of the public API, then it can hide an attribute or facet from the tag documentation.

I will wait for the standard 72 hours for negative feedback, and if I don't receive any I will update the XSL files to simply pass through all mfp:* elements without a white-list approach.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[Nutulapati, Krishna]

Hello All,
I have following issues while handling  jsf with  trinidad.

> The issues I have are as follows.
> I need to develop 2 screens.
> 1)ItemHome:-  In this jsf page, I need to have data table with 6
> columns. One among these Columns need to have tree structure with
> check boxes. The depth of the tree is 2 levels.
> Each node of the tree should contain an item as parent  and 2 sub
> Items as children with checkboxes. User will select one among these
> items (parent item) and clicks edit Item Tab.
> (Problem I have here is how to provide tree structure in the table
> with
> checkboxes)
>
>
> 2)EditItem:- Here a data table is displayed with a selected master

item,

> and its subItems(at most   three),with radio buttons. User will select
> one among these radiobuttons, and should able see the selected object
> in the top panel in editable format. User should able to  edit the
> item/sub Item  and save it in the database.
>
> Here the problem I have is displaying the objects in data table  with
> radio buttons, and allow the user to select one among many radio
> buttons. How can I capture the event of selected radio button in the
> backing bean, and identify the object. (I could not able to find the
> solution).
>
> As I'm reaching deadlines, any of your help in these issues is highly
> appreciated.
> I also attached the screens here, though I'm not sure whether you can
> receive them as attachment.
>
> Thanks
> Krishna

[Scott O'Bryan]

Changing the subject of this post.

Nutulapati, Krishna wrote:

> Hello All,
> I have following issues while handling  jsf with  trinidad.
>  
>> The issues I have are as follows.
>> I need to develop 2 screens.
>> 1)ItemHome:-  In this jsf page, I need to have data table with 6
>> columns. One among these Columns need to have tree structure with
>> check boxes. The depth of the tree is 2 levels.
>> Each node of the tree should contain an item as parent  and 2 sub
>> Items as children with checkboxes. User will select one among these
>> items (parent item) and clicks edit Item Tab.
>> (Problem I have here is how to provide tree structure in the table
>> with
>> checkboxes)
>>
>>
>> 2)EditItem:- Here a data table is displayed with a selected master
>>    
> item,
>  
>> and its subItems(at most   three),with radio buttons. User will select
>> one among these radiobuttons, and should able see the selected object
>> in the top panel in editable format. User should able to  edit the
>> item/sub Item  and save it in the database.
>>
>> Here the problem I have is displaying the objects in data table  with
>> radio buttons, and allow the user to select one among many radio
>> buttons. How can I capture the event of selected radio button in the
>> backing bean, and identify the object. (I could not able to find the
>> solution).
>>
>> As I'm reaching deadlines, any of your help in these issues is highly
>> appreciated.
>> I also attached the screens here, though I'm not sure whether you can
>> receive them as attachment.
>>
>> Thanks
>> Krishna

[My Faces - Dev mailing list]

     [ https://issues.apache.org/jira/browse/TRINIDAD-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Robinson resolved TRINIDAD-1056.
---------------------------------------

       Resolution: Fixed
    Fix Version/s: 1.2.7-plugins

Fixed on trunk and 1.2.6.1. I blacklisted many mfp: elements so that the resultant faces-config.xml is mostly the same. Adding new mfp: elements will automatically be copied over now

> Chang maven-faces-plugin to stop filtering out metadata
> --------------------------------------------------------
>
>                 Key: TRINIDAD-1056
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1056
>             Project: MyFaces Trinidad
>          Issue Type: New Feature
>          Components: Plugins
>    Affects Versions: 1.0.7-core, 1.2.7-core
>            Reporter: Andrew Robinson
>            Assignee: Andrew Robinson
>             Fix For: 1.2.7-plugins
>
>
> The maven-faces-plugin has two xsl files, transform.xsl and transform12.xsl. These files are used to build the final version of the faces-config.xml. Right now they are implemented to support a certain set of elements in the facet-extension and property-extension.
> For example, the XSL code basically says, if there is an <mfp:required/> element under the <property-extension/>, then create a new element called <required/> and apply the templates to its guts.
> This is a very inflexible design as for every new mfp:* property that an IDE adds support for, we have to update the XSL files and ship a new version. I would like to change this so that all mfp:* elements are automatically stripped of the namespace and copied over without filtering. I don't see any value in filtering these out in the plug-in.
> Right now I'd like to add <mfp:hidden/> so that if component B extends component A, but does not want to make one of the properties a part of the public API, then it can hide an attribute or facet from the tag documentation.
> I will wait for the standard 72 hours for negative feedback, and if I don't receive any I will update the XSL files to simply pass through all mfp:* elements without a white-list approach.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.