Re: [Vote] create maven archetype example for portlet bridge
+1 Leonardo Uribe schrieb: > Hi > > I'm solving some issues of archetypes (mvn jetty:run not work) and It could > be good to do another release of this > stuff including the hello world portlet demo as an archetype. > > This is a new module, so in order to follow the protocol, if you have time > please vote if you want to see this > archetype on myfaces-build-tools in the usual way: > > +1 > +0 > -1 but indicating why do not include this. > > regards > > Leonardo Uribe >
[Vote] create maven archetype example for portlet bridge
Hi I'm solving some issues of archetypes (mvn jetty:run not work) and It could be good to do another release of this stuff including the hello world portlet demo as an archetype. This is a new module, so in order to follow the protocol, if you have time please vote if you want to see this archetype on myfaces-build-tools in the usual way: +1 +0 -1 but indicating why do not include this. regards Leonardo Uribe
Re: [Tomahawk] Commit of component generation and 1.2 modules to trunk
>On Tue, Mar 18, 2008 at 10:54 AM, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:
>[1] I'm not sure what the later property examples on that page are meant
>to be; as Leonardo has written them they are attached to no function
>which is not what I had in mind...
Thanks Simon for make more clear this on the wiki page. I have also added
comments about how
should work isSetFieldMethod and isGetLocalMethod attributes for @
mfp.property.
On Tue, Mar 18, 2008 at 12:44 PM, Andrew Robinson <
[EMAIL PROTECTED]> wrote:
> On Tue, Mar 18, 2008 at 9:54 AM, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
> > Hi Andrew,
> >
> > Andrew Robinson schrieb:
> >
> > > One major drawback to the javadoc annotation approach has been left
> > > out and that is attribute reuse. The maven-faces-plugin allows you to
> > > import XML fragments using XPath. So in Trinidad, onclick,
> > > onmouseover, onmouseout, etc. you can import one XML file and not
> have
> > > to re-define all these. But with the javadoc approach, you have to
> > > either one, try to hack the code to extend other classes, two have
> > > some weird interface usage to import these. Either way, the object
> > > hierarchy has to be hacked to get it to work.
> > >
> >
> > Hmm..interesting. So trinidad has cases where a class X is not related
> > to A by inheritance, but does want to provide the same properties as A?
> >
> > Java currently defines "implements" and "extends"; sounds like Trinidad
> > has invented a new OO concept, "emulates" :-).
>
> No, it only imports certain attributes, not all of them. Take some
> time to look at the trinidad-build project and how it works. It is
> better to see than explain.
>
In tomahawk, there are interfaces like
org.apache.myfaces.component.UserRoleAware that define getter and setter
methods for a particular group of related properties. Maybe we can do
something like this:
/**
* @mfp.interface //or propertiesinterface or setofproperties or anything
related
**/
public interface UserRoleAware
{
static final String ENABLED_ON_USER_ROLE_ATTR = "enabledOnUserRole";
static final String VISIBLE_ON_USER_ROLE_ATTR = "visibleOnUserRole";
/**
* @mfp.property
**/
String getEnabledOnUserRole();
void setEnabledOnUserRole(String userRole);
/**
* @mfp.property
**/
String getVisibleOnUserRole();
void setVisibleOnUserRole(String userRole);
}
Then the abstract component class can implements this interface and finally
the generated class must implement the methods. In this way we make clearer
the API, and eliminate in a clean way the advantage of using xml files.
regards
Leonardo Uribe
[jira] Created: (TRINIDAD-1015) SessionChangeManager - Need support for applying changes to a different component than the immediate target, need for supporting ChangeMarker
SessionChangeManager - Need support for applying changes to a different component than the immediate target, need for supporting ChangeMarker - Key: TRINIDAD-1015 URL: https://issues.apache.org/jira/browse/TRINIDAD-1015 Project: MyFaces Trinidad Issue Type: Improvement Environment: Not applicable Reporter: Prakash Udupa N Component changes that are added to SessionChangeManager are applied while the components are being created by the tag handlers. Specifically UIXComponentELTag._applyChanges() and UIXComponentELTag.doEndTag() does this job. Changes are applied only if the component was created newly during tag execution. UIComponentELTag.getCreated() is consulted for this purpose. There are certain type of changes that are registered on a particular target component, but actually need to be applied on a different component to make the change effective. Consider example of a MoveComponentChange specialization that moves components within the view tree. There are three participants in this change: 1. The component that is to be moved. 2. The parent at the destination of the move. 3. The neighboring sibling at the destination to be able to position the component rightly after the move. At the outset this seems to be a change to be recorded against the component that is to be moved (i.e. #1). However, this change needs to be applied actually on the nearest common root parent of the tree that #1 and #2 belongs to. During tag execution (createview/restoreview), the component for #1 gets created, however the common root never gets created. UIXComponentELTag.getCreated() returns false for the common root, as a result, from the current behavior in UIXComponentELTag._applyChanges(), this type of change never gets applied correctly. Proposal is to: a) Provide a ChangeMarker interface that clients could register against the immediately apparent target component (In the above example it is component in #1). b) Improve UIXComponentELTag such that upon applying changes, if a ChangeMarker is encountered instead of a Change, do not apply any change, but ask the ChangeMarker for actual target. Subsequently mark the tag for the new target component as forcibly needing change. This ensures that the Change is correctly applied on the actual target at later point in time. c) UIXComponentELTag, will consult getCreated() as well as check if a change application is forced while applying change. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1014) document skin additions in the Apache MyFaces Trinidad Skinning dev guide.
[ https://issues.apache.org/jira/browse/TRINIDAD-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman resolved TRINIDAD-1014. -- Resolution: Fixed will be fixed in 1.2.8 and 1.0.8 or whenever we post this doc. > document skin additions in the Apache MyFaces Trinidad Skinning dev guide. > -- > > Key: TRINIDAD-1014 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1014 > Project: MyFaces Trinidad > Issue Type: Improvement > Components: Skinning >Reporter: Jeanne Waldman >Assignee: Jeanne Waldman > > Right now there is no mention of the skin-addition element that goes in the > trinidad-skins.xml file. > We need some documentation for this and its elements - style-sheet-name, > bundle-name, and translation-source. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1014) document skin additions in the Apache MyFaces Trinidad Skinning dev guide.
[ https://issues.apache.org/jira/browse/TRINIDAD-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580079#action_12580079 ] Jeanne Waldman commented on TRINIDAD-1014: -- Make sure to mention that the custom component developer should choose a unique style-sheet-name. The reason is we use the ClassLoader's getResource with the style-sheet-name, and if the name is the same as another style-sheet-name in another jar on the classpath, then the file in the jar that is first on the classpath will be returned. To date, this has never been a problem. > document skin additions in the Apache MyFaces Trinidad Skinning dev guide. > -- > > Key: TRINIDAD-1014 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1014 > Project: MyFaces Trinidad > Issue Type: Improvement > Components: Skinning >Reporter: Jeanne Waldman >Assignee: Jeanne Waldman > > Right now there is no mention of the skin-addition element that goes in the > trinidad-skins.xml file. > We need some documentation for this and its elements - style-sheet-name, > bundle-name, and translation-source. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1214) allow to process form submits in a queue for high-speed input handling
[ https://issues.apache.org/jira/browse/TOMAHAWK-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580077#action_12580077 ] Ernst Fastl commented on TOMAHAWK-1214: --- Sound like a cool feature. There are 2 things which I do not yet completely understand: 1.) What is the event which leads to the storage of the form data in the queue -a button which is clicked? -every time a value of one of the inputs changed? 2.) What is the "acting" component which submits one set of queue? what should happen after that? -just updateModel? -actionListener or action? -will be done by valueChangeListeners of the input components? could also be that I misunderstood the idea - in any case - further clarification would be nice :-) > allow to process form submits in a queue for high-speed input handling > -- > > Key: TOMAHAWK-1214 > URL: https://issues.apache.org/jira/browse/TOMAHAWK-1214 > Project: MyFaces Tomahawk > Issue Type: New Feature > Components: PPRPanelGroup >Reporter: Mario Ivankovits >Assignee: Ernst Fastl > > Enhance the PPR stuff in a way which allows to process form input asynchron > in a queue for high-speed input handling. > Probably by adding a new attribute to the PPRPanelGroup called > "queued=true|false". With "true" the form data should be collected and held > in a queue on client side. > The client then checks that queue at given intervalls (queueCheckInterval=) > if there is data in the queue and transmit that data to the server like a > normal ppr request. Between each transmit a queueWaitInterval= should be > waited. > A status component (queueShowStatus=true|false) should show the success of > each transmit. A client side javascript should be used to extract the status > text information from the form data > (queueShowStatusInfoBuilder=javascript-method-name(formData)) > The PprPanelGroup should also be enhanced to being able to point to the > messages component (messages=component-id) the queueStatus information should > then be able to visualize that text and show e.g. a red-cross if there were > errors (=messages) > For this first version the status info can be a simple table created > client-side using some css to allow to format it according to the application > skin. > A simple table with two columns > status-info|return-visualization > status-info is the text returned by the queueShowStatusInfoBuilder javascript > method and return-visualization might be an icon. > Only waiting requests and those with errors should be shown, correctly > finished requests can be removed from the list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1014) document skin additions in the Apache MyFaces Trinidad Skinning dev guide.
document skin additions in the Apache MyFaces Trinidad Skinning dev guide. -- Key: TRINIDAD-1014 URL: https://issues.apache.org/jira/browse/TRINIDAD-1014 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Reporter: Jeanne Waldman Assignee: Jeanne Waldman Right now there is no mention of the skin-addition element that goes in the trinidad-skins.xml file. We need some documentation for this and its elements - style-sheet-name, bundle-name, and translation-source. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1013) add better documentation on what can go into trinidad-skins.xml's style-sheet-name parameter
[ https://issues.apache.org/jira/browse/TRINIDAD-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman resolved TRINIDAD-1013. -- Resolution: Fixed fixed on trunk and trunk1.2.x > add better documentation on what can go into trinidad-skins.xml's > style-sheet-name parameter > > > Key: TRINIDAD-1013 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1013 > Project: MyFaces Trinidad > Issue Type: Improvement >Reporter: Jeanne Waldman >Assignee: Jeanne Waldman > > Someone was asking me if they could have a style-sheet-name in > trinidad-skins.xml that isn't relative to the trinidad-skins file. > Yes, they can add an URL there, like something that begins with http:, > https:, file:, jar:, ftp: > This should be documented in the Apache MyFaces Trinidad Skinning doc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1011) Add new properties to the maven-faces-plugin
[ https://issues.apache.org/jira/browse/TRINIDAD-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-1011. --- Resolution: Fixed Fix Version/s: 1.2.7-plugins Committed to 1.2.6.1 and trunk (1.2.7-SNAPSHOT) > Add new properties to the maven-faces-plugin > > > Key: TRINIDAD-1011 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1011 > Project: MyFaces Trinidad > Issue Type: Improvement > Components: Plugins >Affects Versions: 1.0.7-core, 1.2.7-core >Reporter: Andrew Robinson >Assignee: Andrew Robinson > Fix For: 1.2.7-plugins > > > Looking to add 2 new properties to be supported for the maven faces plug-in > that will be leveraged in JDev: > mfp:grouping-element - allow the user to specify when multiple child > components are being added to a facet, what wrapping component to use to > ensure that there is only one child per facet. Example usage: > > My facet > myfacet > > > > > > > > > In this case, if two elements are added to "myfacet", then the IDE should > wrap them in a tr:panelGroupLayout. > Purpose: to allow the component developer to control the grouping element to > be added by default as a wrapper for components that desire special children > to be used. > Second property: is-content-resizable > This instructs the IDE that content in a facet is not resizable. This is > useful as there are some components that stretch their children and thus it > is confusing to let the user alter the size in the IDE when it will not be > used during run time. Example usage: > > My facet > myfacet > > > false > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] implementing tabIndex attributes on select components
On Tue, Mar 18, 2008 at 12:47 PM, Gabrielle Crawford <[EMAIL PROTECTED]> wrote: > Unfortunately I can't remember the details. Blake Sullivan and Andy > Schwartz aren't around this week, but they may know more. Not a problem, I don't see myself getting too much done this week with Easter coming up. > What happens to components that don't have a tabindex set, meaning do > you have to set it on everything in the page once you set it on one thing? That is the way of HTML, this isn't a Trinidad consideration, but something specific to writing web sites. Note that you don't have to set all the tab indexes, but only the ones that you want to get focus first (as I mentioned, elements without tab indexes are tabbed too after all the explicit ones). So if I have a log in form, the tab indexes would probably be: user name: 1 password: 2 submit: 3 And then everything else would not have one. This way all the "template" components would be tabbed, just not first.
[jira] Resolved: (TOBAGO-638) Sheet paging to certain Page/Row sometimes fail
[ https://issues.apache.org/jira/browse/TOBAGO-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-638. -- Resolution: Fixed merged to 1.0.x branch > Sheet paging to certain Page/Row sometimes fail > --- > > Key: TOBAGO-638 > URL: https://issues.apache.org/jira/browse/TOBAGO-638 > Project: MyFaces Tobago > Issue Type: Bug > Components: Themes >Affects Versions: 1.0.15 >Reporter: Volker Weber >Assignee: Bernd Bohmann >Priority: Minor > Fix For: 1.0.16, 1.1.0 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] implementing tabIndex attributes on select components
Unfortunately I can't remember the details. Blake Sullivan and Andy Schwartz aren't around this week, but they may know more. What happens to components that don't have a tabindex set, meaning do you have to set it on everything in the page once you set it on one thing? Thanks, Gab Andrew Robinson wrote: On Tue, Mar 18, 2008 at 11:28 AM, Gabrielle Crawford <[EMAIL PROTECTED]> wrote: I know this has been considered many times in the past, but not implemented due to complexity. What complexity are you referring to? Could you please provide concrete examples? Thanks. When you know the details of the implementation, can you start a new thread with [Trinidad] in the subject? Done, but kept the reply ID intact for threaded email reading. How will it work with stamping, components with multiple tab stops, etc. Tab indexes do not have to be unique. Browsers support this as it is a w3c requirement. Example: The browser will tab to the first element with 5 first, then to each element with 5 next. After all of the 5's are visited it will go to the 7's as there are none with a tab index of 6. The last anchor gets a default tab stop that will be focused after every element that has an explicit tab stop has already been visited. So stamping is not an issue if implemented correctly (all components in a table are given the same tab index). If users want different tab indexes per component, per row, the tabIndex supports EL, so users can "easily" program around this problem by incrementing something like a counter in a backing bean. Example: or: Please see the specification for more information on the tabIndex: http://www.w3.org/TR/html4/interact/forms.html#adef-tabindex
[Trinidad] implementing tabIndex attributes on select components
On Tue, Mar 18, 2008 at 11:28 AM, Gabrielle Crawford <[EMAIL PROTECTED]> wrote: > I know this has been considered many times in the past, but not > implemented due to complexity. What complexity are you referring to? Could you please provide concrete examples? Thanks. > When you know the details of the implementation, can you start a new > thread with [Trinidad] in the subject? Done, but kept the reply ID intact for threaded email reading. > How will it work with stamping, > components with multiple tab stops, etc. Tab indexes do not have to be unique. Browsers support this as it is a w3c requirement. Example: The browser will tab to the first element with 5 first, then to each element with 5 next. After all of the 5's are visited it will go to the 7's as there are none with a tab index of 6. The last anchor gets a default tab stop that will be focused after every element that has an explicit tab stop has already been visited. So stamping is not an issue if implemented correctly (all components in a table are given the same tab index). If users want different tab indexes per component, per row, the tabIndex supports EL, so users can "easily" program around this problem by incrementing something like a counter in a backing bean. Example: or: Please see the specification for more information on the tabIndex: http://www.w3.org/TR/html4/interact/forms.html#adef-tabindex
[jira] Commented: (TOBAGO-130) Maven Apt Plugin should support plugin dependencies
[ https://issues.apache.org/jira/browse/TOBAGO-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579948#action_12579948 ] Mark Hobson commented on TOBAGO-130: See http://jira.codehaus.org/browse/MOJO-1072 for a fix for this under the Codehaus Mojo apt-maven-plugin. I've sent an email to [EMAIL PROTECTED] enquiring about the differences between these two similar plugins. I can follow-up on the myfaces mailing list if there's any interest? > Maven Apt Plugin should support plugin dependencies > --- > > Key: TOBAGO-130 > URL: https://issues.apache.org/jira/browse/TOBAGO-130 > Project: MyFaces Tobago > Issue Type: Improvement > Components: Maven Apt Plugin >Affects Versions: 1.0.8 >Reporter: Bernd Bohmann >Priority: Minor > > Due Classloader issues this could only work if the apt process is forked. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1013) add better documentation on what can go into trinidad-skins.xml's style-sheet-name parameter
add better documentation on what can go into trinidad-skins.xml's style-sheet-name parameter Key: TRINIDAD-1013 URL: https://issues.apache.org/jira/browse/TRINIDAD-1013 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Jeanne Waldman Assignee: Jeanne Waldman Someone was asking me if they could have a style-sheet-name in trinidad-skins.xml that isn't relative to the trinidad-skins file. Yes, they can add an URL there, like something that begins with http:, https:, file:, jar:, ftp: This should be documented in the Apache MyFaces Trinidad Skinning doc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Tomahawk] Commit of component generation and 1.2 modules to trunk
On Tue, Mar 18, 2008 at 9:54 AM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Hi Andrew,
>
> Andrew Robinson schrieb:
>
> > One major drawback to the javadoc annotation approach has been left
> > out and that is attribute reuse. The maven-faces-plugin allows you to
> > import XML fragments using XPath. So in Trinidad, onclick,
> > onmouseover, onmouseout, etc. you can import one XML file and not have
> > to re-define all these. But with the javadoc approach, you have to
> > either one, try to hack the code to extend other classes, two have
> > some weird interface usage to import these. Either way, the object
> > hierarchy has to be hacked to get it to work.
> >
>
> Hmm..interesting. So trinidad has cases where a class X is not related
> to A by inheritance, but does want to provide the same properties as A?
>
> Java currently defines "implements" and "extends"; sounds like Trinidad
> has invented a new OO concept, "emulates" :-).
No, it only imports certain attributes, not all of them. Take some
time to look at the trinidad-build project and how it works. It is
better to see than explain.
>
> While I haven't analysed this carefully, I see no reason why there
> couldn't be an extra annotation attribute:
>
> /**
> * @mfp.component emulates="javax.faces.UIData" ...
> */
> class TrinidadData .. {...}
>
> which would cause the plugin to look up the metadata for the
> javax.faces.UIData component then simply copy all the property
> definitions for that class into the metadata for the TrinidadData class.
>
> Would that satisfy the trinidad requirement?
Nope, would definitely not work. It would have to be located outside
of a Java file
-Andrew
[jira] Updated: (PORTLETBRIDGE-30) Null pointer exception if session closed after portlet destroyed
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman updated PORTLETBRIDGE-30: -- Resolution: Fixed Status: Resolved (was: Patch Available) Fix committed -- BridgeImpl modified to check if bridge has been destoryed before attempting to remove request scopes. > Null pointer exception if session closed after portlet destroyed > > > Key: PORTLETBRIDGE-30 > URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-30 > Project: MyFaces Portlet Bridge > Issue Type: Bug > Components: Impl >Affects Versions: 1.0.0-alpha, 1.0.0-alpha-2, 1.0.0, 2.0.0 >Reporter: Michael Freedman >Assignee: Michael Freedman > Fix For: 1.0.0, 2.0.0 > > Attachments: jira_30_1.0.patch, jira_30_2.0.patch > > > If the bridge is called to remove its requestScopes from a > session.valueUnbound after the bridge has been destroyed an Exception is > thrown. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (PORTLETBRIDGE-30) Null pointer exception if session closed after portlet destroyed
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman updated PORTLETBRIDGE-30: -- Status: Patch Available (was: Open) > Null pointer exception if session closed after portlet destroyed > > > Key: PORTLETBRIDGE-30 > URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-30 > Project: MyFaces Portlet Bridge > Issue Type: Bug > Components: Impl >Affects Versions: 1.0.0-alpha, 1.0.0-alpha-2, 1.0.0, 2.0.0 >Reporter: Michael Freedman >Assignee: Michael Freedman > Fix For: 1.0.0, 2.0.0 > > Attachments: jira_30_1.0.patch, jira_30_2.0.patch > > > If the bridge is called to remove its requestScopes from a > session.valueUnbound after the bridge has been destroyed an Exception is > thrown. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: chooseColor: does tabIndex make any sense?
I know this has been considered many times in the past, but not implemented due to complexity. When you know the details of the implementation, can you start a new thread with [Trinidad] in the subject? How will it work with stamping, components with multiple tab stops, etc. Thanks, Gab Andrew Robinson wrote: I'm confused though, are you just controlling the number of tab stops in the implementation? Meaning you're not trying to add a public api for the user to control tab stops on the page, are you? The bug is to add a tabIndex attribute onto certain components so that users have control over the tab order of a Trinidad JSF page. Other component libraries (even the JSF core libraries) have this support: http://java.sun.com/javaee/javaserverfaces/1.2/docs/tlddocs/h/inputText.html (note: there it is called tabindex, not tabIndex, but I thought tabIndex is more in line with how trinidad component attributes are named.) -Andrew
[jira] Created: (PORTLETBRIDGE-30) Null pointer exception if session closed after portlet destroyed
Null pointer exception if session closed after portlet destroyed Key: PORTLETBRIDGE-30 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-30 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 1.0.0-alpha-2, 1.0.0-alpha, 1.0.0, 2.0.0 Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 1.0.0, 2.0.0 If the bridge is called to remove its requestScopes from a session.valueUnbound after the bridge has been destroyed an Exception is thrown. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Tomahawk] Commit of component generation and 1.2 modules to trunk
On Tue, Mar 18, 2008 at 10:54 AM, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: > > [1] I'm not sure what the later property examples on that page are meant > to be; as Leonardo has written them they are attached to no function > which is not what I had in mind... > The examples that does not have methods on bottom are this: /** //Sometimes this should be used for exclude one unwanted inherited property from the tld. * //The exclusion only works for the class where is defined. * @mfp.property * name = "parentProperty1" * exclude = "true" **/ Example: org.apache.myfaces.custom.HtmlTag has value property on tld, but org.apache.myfaces.custom.Div do not, becase it always returns a static value: div. This comment does just affect tld generation. /** //Sometimes this should be used for override documentation * * This property is used here for . * * * @mfp.property * name = "parentProperty2" * desc = "This property is used here for . " **/ Example: On 1.2 javax.faces.component.HtmlPanelGroup has layout property. There are a lot of components that override this method changing its meaning, so it's necessary that on tld javadoc (constructed from .tld) we can find the real meaning for this component. Other common example is value property. It could be good if we can override the doc on some components. This comment does just affect tld generation. > > Regards, > Simon > >
[jira] Reopened: (TOBAGO-619) Avoid usages of javascript:false in iframe src attribute
[ https://issues.apache.org/jira/browse/TOBAGO-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann reopened TOBAGO-619: -- > Avoid usages of javascript:false in iframe src attribute > > > Key: TOBAGO-619 > URL: https://issues.apache.org/jira/browse/TOBAGO-619 > Project: MyFaces Tobago > Issue Type: Improvement > Components: Themes >Affects Versions: 1.0.14 >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann >Priority: Minor > Fix For: 1.0.16, 1.1.0 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Tomahawk] Commit of component generation and 1.2 modules to trunk
Hi Andrew,
Andrew Robinson schrieb:
> One major drawback to the javadoc annotation approach has been left
> out and that is attribute reuse. The maven-faces-plugin allows you to
> import XML fragments using XPath. So in Trinidad, onclick,
> onmouseover, onmouseout, etc. you can import one XML file and not have
> to re-define all these. But with the javadoc approach, you have to
> either one, try to hack the code to extend other classes, two have
> some weird interface usage to import these. Either way, the object
> hierarchy has to be hacked to get it to work.
>
Hmm..interesting. So trinidad has cases where a class X is not related
to A by inheritance, but does want to provide the same properties as A?
Java currently defines "implements" and "extends"; sounds like Trinidad
has invented a new OO concept, "emulates" :-).
While I haven't analysed this carefully, I see no reason why there
couldn't be an extra annotation attribute:
/**
* @mfp.component emulates="javax.faces.UIData" ...
*/
class TrinidadData .. {...}
which would cause the plugin to look up the metadata for the
javax.faces.UIData component then simply copy all the property
definitions for that class into the metadata for the TrinidadData class.
Would that satisfy the trinidad requirement?
> Also, the java-annotation-javadoc approach is odd that code must be
> filled in. The Java files would have some sort of attribute
> definitions, but no body (I don't want to have to waste time writing
> setters & getters when I should only have to write a definition for an
> attribute).
>
Yes, there does need to be something to attach property annotations to.
I would suggest an abstract getter method:
/**
* An identifier for this component which is unique within the
enclosing NamingContainer.
*
* @mfp.property literalOnly=true
*/
public String getId();
rather than annotating a private class member. After all, there might
not *be* a real class member; the data might be stored in the
attributes map for example. This is shown in the first property example
here [1]:
http://wiki.apache.org/myfaces/MyfacesBuilderPlugin
By defining the getter method as above, the plugin can inspect the
return type to determine the property type automatically (so the
annotation doesn't have to specify it). I guess it is possible to do
away with the method completely, and just have a free-standing
annotation, but (a) that look weird, and (b) the annotation has to be
more complex because we have to explicitly provide property name and
type rather than looking at the method definition.
Note that because the method is defined as a normal java method, code in
a renderer (for example) can be written to call that method and will
still compile even before the code-generator has been run. Not critical,
but nice.
I don't see any need to define the corresponding setter method.
Just in case it isn't clear, the javadoc above can be used as the
property description field for the tld (first sentence -> short
description, and the remainder for long description).
Is this more work than defining the equivalent xml?
[1] I'm not sure what the later property examples on that page are meant
to be; as Leonardo has written them they are attached to no function
which is not what I had in mind...
> Personally, I much prefer the Trinidad approach, and I have found it
> easy to use, except for the *Template files (there has to be a better
> way than that as they are not IDE friendly).
>
Regards,
Simon
Re: [Tomahawk] Commit of component generation and 1.2 modules to trunk
Hi,
[EMAIL PROTECTED] napsal(a):
Sochor Zdeněk schrieb:
Generally extending components by adding whole bucket of local
property/getter/setter seems not right for me because
it's meant to provide just another feature not used by many people.
Wouldn't it be more cleaner to just use that property as attribute (in
JSF api's speach):
storing/using it from getAttributes() map?
This way it would just be needed to generate TLD/Tag entries, no
customization of component's code needed.
Also renderer has full access to attributes map by default ;)
Nice side-effect to this approach is eventual speeding-up processing
by adding cache to getAttributes() MyFaces map:
storing already resolved values in transient map to avoid multiple
resolving during lifecycle.
The disadvantage of using attributes are:
* all typesafety is lost.
This can be assured in tag/handler, also for JSF 1.2 isn't it handled by
deferred-type declaration in tld?
* the attributes are not self-documenting, like explicit setter/getter
methods are. For code, you can see that a property exists on a class,
but cannot see what attributes might affect its behaviour. And for tags,
the property in the tld tells people that the option exists; hiding it
in an attribute makes it harder to find.
In Tomahawk (1.1 based) there are some hidden lines in one property
which modify other properties thus affecting behavior, so nothing new here.
But generally i have to agree.
So in general I would currently be in favour of properties not attributes.
Just general trend ;)
There's no reason why the setter/getter cannot store data into the
attributes map behind the scenes if that turns out to be a useful
optimisation. By having a setter method, the actual way the data is
stored is hidden; we can then optimise in whatever way works best.
* Use case 3:
I create a new project (eg commons widgets)
With the xml-files approach, I need to create two maven modules, one for
the code and one for the builder stuff. Somehow I need to get access to
all the metadata defined by the core build project (??). I then need to
create metadata files for my project that (somehow) add info about my
new components.
With the doc-annotation approach, I just create a project for my code,
add the builder plugin to my pom, and add annotations to any of my
converters/validators/components. Done.
A question about properties inheritance accross components arise:
i really think that having the same propetry handled by multiple
components in hiearchy is bad (quite common in Tomahawk).
Also the Tomahawk code should use consistent way in components and
tags inheritances.
There should be a way to filter already defined properties in either
approach.
Sorry, I don't understand this comment at all.
With what I am proposing, an ancestor class will define a property (eg
getId/setId) and an annotation will be added on that method definition.
Then the derived class does nothing; the plugin walks the ancestry tree
and figures out that there is an inherited property of that name.
Imagine nowadays "standard'" attribute styleClass, it's defined in
almost all tld tags, but sometimes it's implemented as property in more than
one concrete class in the same hierarchy. Now the question is - which
class should work with it (for me the base), BUT the last concrete class
- used component
will generate its own setter/getter AND tag's setter - is it OK? (for me
NOT).
Also, when i think of class hiearchy and code readability/debug info -
in runtime we'll see pointers to generated class's lines, won't we?
Another thing is generating "middle" components in hiearchy ("->" = extends)
e.g. for 2 components now implemented as basic->extending would be
basic abstract->generated concrete basic and now what:
-> abstract ext. ->generated concrete ext. or
-> concrete ext.
because
abstract basic -> abstract ext. and then generating 2 concrete classes
would lost inheritance (concrete_ext instanceof concrete_basic = false)
* Use case 4:
A JSF newbie browses the myfaces-impl code.
With the xml-files approach, he needs to also browse the xml files in
the build project or alternatively browse the generated code to get any
idea of how things work.
With the doc-annotation approach, the annotations are there for him to
see on the checked-in classes.
This use-case is not clear - it's quite different to look at code to
see how components work and to look at renderers' stuff.
IMO more people are interested in renderers, so both approaches are
almost the same for them.
Agreed, generated components that subclass a package-private base
(core-api) is always going to be confusing. In either case, the renderer
is casting to a type that does not exist until the plugin has been run.
However in all other projects (core-impl, tomahawk, etc) we can have the
component base class public. Then with the doc-annotation approach, the
renderer can cast to that base (non-gener
Re: [Tomahawk] Commit of component generation and 1.2 modules to trunk
One major drawback to the javadoc annotation approach has been left out and that is attribute reuse. The maven-faces-plugin allows you to import XML fragments using XPath. So in Trinidad, onclick, onmouseover, onmouseout, etc. you can import one XML file and not have to re-define all these. But with the javadoc approach, you have to either one, try to hack the code to extend other classes, two have some weird interface usage to import these. Either way, the object hierarchy has to be hacked to get it to work. Also, the java-annotation-javadoc approach is odd that code must be filled in. The Java files would have some sort of attribute definitions, but no body (I don't want to have to waste time writing setters & getters when I should only have to write a definition for an attribute). Personally, I much prefer the Trinidad approach, and I have found it easy to use, except for the *Template files (there has to be a better way than that as they are not IDE friendly). -Andrew
[jira] Created: (TOBAGO-638) Sheet paging to certain Page/Row sometimes fail
Sheet paging to certain Page/Row sometimes fail --- Key: TOBAGO-638 URL: https://issues.apache.org/jira/browse/TOBAGO-638 Project: MyFaces Tobago Issue Type: Bug Reporter: Volker Weber Assignee: Volker Weber Priority: Minor Fix For: 1.0.16, 1.1.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Tomahawk] Commit of component generation and 1.2 modules to trunk
Sochor Zdeněk schrieb: > Generally extending components by adding whole bucket of local > property/getter/setter seems not right for me because > it's meant to provide just another feature not used by many people. > Wouldn't it be more cleaner to just use that property as attribute (in > JSF api's speach): > storing/using it from getAttributes() map? > This way it would just be needed to generate TLD/Tag entries, no > customization of component's code needed. > Also renderer has full access to attributes map by default ;) > Nice side-effect to this approach is eventual speeding-up processing > by adding cache to getAttributes() MyFaces map: > storing already resolved values in transient map to avoid multiple > resolving during lifecycle. The disadvantage of using attributes are: * all typesafety is lost. * the attributes are not self-documenting, like explicit setter/getter methods are. For code, you can see that a property exists on a class, but cannot see what attributes might affect its behaviour. And for tags, the property in the tld tells people that the option exists; hiding it in an attribute makes it harder to find. So in general I would currently be in favour of properties not attributes. There's no reason why the setter/getter cannot store data into the attributes map behind the scenes if that turns out to be a useful optimisation. By having a setter method, the actual way the data is stored is hidden; we can then optimise in whatever way works best. >> * Use case 3: >> >> I create a new project (eg commons widgets) >> >> With the xml-files approach, I need to create two maven modules, one for >> the code and one for the builder stuff. Somehow I need to get access to >> all the metadata defined by the core build project (??). I then need to >> create metadata files for my project that (somehow) add info about my >> new components. >> >> With the doc-annotation approach, I just create a project for my code, >> add the builder plugin to my pom, and add annotations to any of my >> converters/validators/components. Done. >> >> > A question about properties inheritance accross components arise: > i really think that having the same propetry handled by multiple > components in hiearchy is bad (quite common in Tomahawk). > Also the Tomahawk code should use consistent way in components and > tags inheritances. > There should be a way to filter already defined properties in either > approach. Sorry, I don't understand this comment at all. With what I am proposing, an ancestor class will define a property (eg getId/setId) and an annotation will be added on that method definition. Then the derived class does nothing; the plugin walks the ancestry tree and figures out that there is an inherited property of that name. >> * Use case 4: >> >> A JSF newbie browses the myfaces-impl code. >> >> With the xml-files approach, he needs to also browse the xml files in >> the build project or alternatively browse the generated code to get any >> idea of how things work. >> >> With the doc-annotation approach, the annotations are there for him to >> see on the checked-in classes. >> >> > This use-case is not clear - it's quite different to look at code to > see how components work and to look at renderers' stuff. > IMO more people are interested in renderers, so both approaches are > almost the same for them. Agreed, generated components that subclass a package-private base (core-api) is always going to be confusing. In either case, the renderer is casting to a type that does not exist until the plugin has been run. However in all other projects (core-impl, tomahawk, etc) we can have the component base class public. Then with the doc-annotation approach, the renderer can cast to that base (non-generated) type, and invoke the abstract methods. The result is code that will compile correctly after a direct checkout, even without the plugin having been run. That seems nice. The same *is* possible with the xml-files approach, but is duplicated work: the class and its properties have to be defined in the xml files too. And if the code and xml are not kept correctly in sync, then problems will occur. Regards, Simon
Re: [Tomahawk] Commit of component generation and 1.2 modules to trunk
Hi Martin, Martin Marinschek napsal(a): Hi Zdenek, *saved=solved regards, Martin On 3/18/08, Martin Marinschek <[EMAIL PROTECTED]> wrote: Hi Zdenek, you seem to ignore my comments - you will need to provide the setters, this is in the spec - and there is component-binding, so you need to provide them? Sorry, just one misinterpretation. The talk in use-case 1 was about *new* property. I wasn't talking about spec's defined *properties* (and in spec only), they are set in stone as value/setter/getter, but all other "things" are up to developers: they can either define them as *properties* or *attributes*. Even html renderkit defines *attributes*, not *properties*. IMO distinction between *property* and *attribute* lays in this - property is needed for component's basic functioning, attribute is to extend behavior or look. This means that writing all *properties* in components is done only once (they don't and can't change), everything else should be *attribute* in map. (that way all saving/restoring is done by default). The only drawback in this is to rewrite renderers and user's custom code to access values from map, not directly by calling getters. Anyway, why should i provide setter for *attribute*? For this i can use jsp tag or facelet taghandler to access map as well (if it's accessing *property*, respective setter will be called from map's implementation by default) And regarding component-binding - it's *property* per spec. BTW, why should i ignore constructive and inspiring comments?? Regards, Zdenek The issue with state-saving will need to be saved another way. regards, Martin On 3/18/08, Sochor Zdeněk <[EMAIL PROTECTED]> wrote: Hi all, comments inline. [EMAIL PROTECTED] napsal(a): The myfaces-builder-plugin stuff is an experiment/proof-of-concept at the current time, That's why the code is in a "branches" directory. No vote has been taken on using this approach; it was necessary to show that this would work before calling a vote to make a choice between this and the myfaces-faces-plugin (formerly trinidad-faces-plugin) approach. But there is enough concrete info there now (particularly thanks to Leonardo's new wiki pages) for us to have a discussion. It's clear that the approach will work; now the community needs to say which approach they think is the most productive for the future. I would personally like to see this used for all projects: core1.1, core1.2, tomahawk, commons and eventually trinidad too. I certainly see no reason why the myfaces-builder-plugin approach cannot be used for trinidad. It's just a matter of extending the "model" classes that hold the metadata. And I see no theoretical reason why the existing .xml files in the build project could not even be used as input to the myfaces-builder-plugin (ie as an alternative to doc comments). Note that the reverse is not true: there is no easy way to use doc comments to feed metadata into the myfaces-faces-plugin, because that is really seriously hard-wired to assume that xml files are its input. But the most important thing to me *is* getting away from the "build project with lots of xml files" approach. == * Use case 1: I want to extend the t:inputDate component to add a property to a component, and alter the renderer to use that property. With the xml-files approach (myfaces-faces-plugin), I open the build project and modify an xml file to add the info using the special xml tags. I then run the plugin. I then refresh my eclipse project. I then alter the renderer to access the new property on the generated component class. Note that just looking at the base component class gives *no* info about what properties that component has. With the doc-annotation approach (myfaces-builder-plugin), I open the normal tomahawk project, and add an abstract getter method (perfectly normal java coding). I then add the appropriate annotation as a doc-annotation. I then modify my renderer (no need to run the code generator; I can write calls to the abstract method fine). And with the doc-annotation approach, looking at the component class shows clearly that it has that property. In addition: (a) the amount of info I need in the annotation is much less than I needed to add to the xml file because the plugin can use introspection on the abstract method declaration (b) javadoc comments attached to the method are used automatically in the .tld etc. Generally extending components by adding whole bucket of local property/getter/setter seems not right for me because it's meant to provide just another feature not used by many people. Wouldn't it be more cleaner to just use that property as attribute (in JSF api's speach): storing/using it from getAttributes() map? This way it would just be needed to generate TLD/Tag entries, no customization of component's code needed. Also renderer has full access to attributes map by default ;) Nice side-effect to this approach is eventual speeding-up
Re: [Tomahawk] Commit of component generation and 1.2 modules to trunk
Hi Zdenek, *saved=solved regards, Martin On 3/18/08, Martin Marinschek <[EMAIL PROTECTED]> wrote: > Hi Zdenek, > > you seem to ignore my comments - you will need to provide the setters, > this is in the spec - and there is component-binding, so you need to > provide them? > > The issue with state-saving will need to be saved another way. > > regards, > > Martin > > On 3/18/08, Sochor Zdeněk <[EMAIL PROTECTED]> wrote: > > Hi all, > > comments inline. > > > > [EMAIL PROTECTED] napsal(a): > > > > > > The myfaces-builder-plugin stuff is an experiment/proof-of-concept at > > > the current time, That's why the code is in a "branches" directory. No > > > vote has been taken on using this approach; it was necessary to show > > > that this would work before calling a vote to make a choice between this > > > and the myfaces-faces-plugin (formerly trinidad-faces-plugin) approach. > > > > > > But there is enough concrete info there now (particularly thanks to > > > Leonardo's new wiki pages) for us to have a discussion. It's clear that > > > the approach will work; now the community needs to say which approach > > > they think is the most productive for the future. > > > > > > I would personally like to see this used for all projects: core1.1, > > > core1.2, tomahawk, commons and eventually trinidad too. I certainly see > > > no reason why the myfaces-builder-plugin approach cannot be used for > > > trinidad. It's just a matter of extending the "model" classes that hold > > > the metadata. And I see no theoretical reason why the existing .xml > > > files in the build project could not even be used as input to the > > > myfaces-builder-plugin (ie as an alternative to doc comments). Note that > > > the reverse is not true: there is no easy way to use doc comments to > > > feed metadata into the myfaces-faces-plugin, because that is really > > > seriously hard-wired to assume that xml files are its input. > > > > > > But the most important thing to me *is* getting away from the "build > > > project with lots of xml files" approach. > > > > > > == > > > > > > * Use case 1: > > > > > > I want to extend the t:inputDate component to add a property to a > > > component, and alter the renderer to use that property. > > > > > > With the xml-files approach (myfaces-faces-plugin), I open the build > > > project and modify an xml file to add the info using the special xml > > > tags. I then run the plugin. I then refresh my eclipse project. I then > > > alter the renderer to access the new property on the generated component > > > class. Note that just looking at the base component class gives *no* > > > info about what properties that component has. > > > > > > With the doc-annotation approach (myfaces-builder-plugin), I open the > > > normal tomahawk project, and add an abstract getter method (perfectly > > > normal java coding). I then add the appropriate annotation as a > > > doc-annotation. I then modify my renderer (no need to run the code > > > generator; I can write calls to the abstract method fine). > > > > > > And with the doc-annotation approach, looking at the component class > > > shows clearly that it has that property. In addition: > > > (a) the amount of info I need in the annotation is much less than I > > > needed to add to the xml file because the plugin can use introspection > > > on the abstract method declaration > > > (b) javadoc comments attached to the method are used automatically in > > > the .tld etc. > > > > > Generally extending components by adding whole bucket of local > > property/getter/setter seems not right for me because > > it's meant to provide just another feature not used by many people. > > Wouldn't it be more cleaner to just use that property as attribute (in > > JSF api's speach): > > storing/using it from getAttributes() map? > > This way it would just be needed to generate TLD/Tag entries, no > > customization of component's code needed. > > Also renderer has full access to attributes map by default ;) > > Nice side-effect to this approach is eventual speeding-up processing by > > adding cache to getAttributes() MyFaces map: > > storing already resolved values in transient map to avoid multiple > > resolving during lifecycle. > > > * Use case 2: > > > > > > I create a new tomahawk converter class. > > > > > > With the xml-files approach, I open the build project and create some > > > new xml files. Then I write the converter class in the main code > project. > > > > > > With the myfaces-builder-plugin approach, I open the main code project, > > > add the class and add a couple of doc-annotations. > > > > > > > > Clearly 2nd option rules :D > > > * Use case 3: > > > > > > I create a new project (eg commons widgets) > > > > > > With the xml-files approach, I need to create two maven modules, one for > > > the code and one for the builder stuff. Somehow I need to get access to > > > all the metadata defined by the core build project (??). I then need to > > > create metadata files
Re: [Tomahawk] Commit of component generation and 1.2 modules to trunk
Hi Zdenek, you seem to ignore my comments - you will need to provide the setters, this is in the spec - and there is component-binding, so you need to provide them? The issue with state-saving will need to be saved another way. regards, Martin On 3/18/08, Sochor Zdeněk <[EMAIL PROTECTED]> wrote: > Hi all, > comments inline. > > [EMAIL PROTECTED] napsal(a): > > > > The myfaces-builder-plugin stuff is an experiment/proof-of-concept at > > the current time, That's why the code is in a "branches" directory. No > > vote has been taken on using this approach; it was necessary to show > > that this would work before calling a vote to make a choice between this > > and the myfaces-faces-plugin (formerly trinidad-faces-plugin) approach. > > > > But there is enough concrete info there now (particularly thanks to > > Leonardo's new wiki pages) for us to have a discussion. It's clear that > > the approach will work; now the community needs to say which approach > > they think is the most productive for the future. > > > > I would personally like to see this used for all projects: core1.1, > > core1.2, tomahawk, commons and eventually trinidad too. I certainly see > > no reason why the myfaces-builder-plugin approach cannot be used for > > trinidad. It's just a matter of extending the "model" classes that hold > > the metadata. And I see no theoretical reason why the existing .xml > > files in the build project could not even be used as input to the > > myfaces-builder-plugin (ie as an alternative to doc comments). Note that > > the reverse is not true: there is no easy way to use doc comments to > > feed metadata into the myfaces-faces-plugin, because that is really > > seriously hard-wired to assume that xml files are its input. > > > > But the most important thing to me *is* getting away from the "build > > project with lots of xml files" approach. > > > > == > > > > * Use case 1: > > > > I want to extend the t:inputDate component to add a property to a > > component, and alter the renderer to use that property. > > > > With the xml-files approach (myfaces-faces-plugin), I open the build > > project and modify an xml file to add the info using the special xml > > tags. I then run the plugin. I then refresh my eclipse project. I then > > alter the renderer to access the new property on the generated component > > class. Note that just looking at the base component class gives *no* > > info about what properties that component has. > > > > With the doc-annotation approach (myfaces-builder-plugin), I open the > > normal tomahawk project, and add an abstract getter method (perfectly > > normal java coding). I then add the appropriate annotation as a > > doc-annotation. I then modify my renderer (no need to run the code > > generator; I can write calls to the abstract method fine). > > > > And with the doc-annotation approach, looking at the component class > > shows clearly that it has that property. In addition: > > (a) the amount of info I need in the annotation is much less than I > > needed to add to the xml file because the plugin can use introspection > > on the abstract method declaration > > (b) javadoc comments attached to the method are used automatically in > > the .tld etc. > > > Generally extending components by adding whole bucket of local > property/getter/setter seems not right for me because > it's meant to provide just another feature not used by many people. > Wouldn't it be more cleaner to just use that property as attribute (in > JSF api's speach): > storing/using it from getAttributes() map? > This way it would just be needed to generate TLD/Tag entries, no > customization of component's code needed. > Also renderer has full access to attributes map by default ;) > Nice side-effect to this approach is eventual speeding-up processing by > adding cache to getAttributes() MyFaces map: > storing already resolved values in transient map to avoid multiple > resolving during lifecycle. > > * Use case 2: > > > > I create a new tomahawk converter class. > > > > With the xml-files approach, I open the build project and create some > > new xml files. Then I write the converter class in the main code project. > > > > With the myfaces-builder-plugin approach, I open the main code project, > > add the class and add a couple of doc-annotations. > > > > > Clearly 2nd option rules :D > > * Use case 3: > > > > I create a new project (eg commons widgets) > > > > With the xml-files approach, I need to create two maven modules, one for > > the code and one for the builder stuff. Somehow I need to get access to > > all the metadata defined by the core build project (??). I then need to > > create metadata files for my project that (somehow) add info about my > > new components. > > > > With the doc-annotation approach, I just create a project for my code, > > add the builder plugin to my pom, and add annotations to any of my > > converters/validators/components. Done. > > > > > A question about properties inherit
Re: [Tomahawk] Commit of component generation and 1.2 modules to trunk
Hi all, comments inline. [EMAIL PROTECTED] napsal(a): The myfaces-builder-plugin stuff is an experiment/proof-of-concept at the current time, That's why the code is in a "branches" directory. No vote has been taken on using this approach; it was necessary to show that this would work before calling a vote to make a choice between this and the myfaces-faces-plugin (formerly trinidad-faces-plugin) approach. But there is enough concrete info there now (particularly thanks to Leonardo's new wiki pages) for us to have a discussion. It's clear that the approach will work; now the community needs to say which approach they think is the most productive for the future. I would personally like to see this used for all projects: core1.1, core1.2, tomahawk, commons and eventually trinidad too. I certainly see no reason why the myfaces-builder-plugin approach cannot be used for trinidad. It's just a matter of extending the "model" classes that hold the metadata. And I see no theoretical reason why the existing .xml files in the build project could not even be used as input to the myfaces-builder-plugin (ie as an alternative to doc comments). Note that the reverse is not true: there is no easy way to use doc comments to feed metadata into the myfaces-faces-plugin, because that is really seriously hard-wired to assume that xml files are its input. But the most important thing to me *is* getting away from the "build project with lots of xml files" approach. == * Use case 1: I want to extend the t:inputDate component to add a property to a component, and alter the renderer to use that property. With the xml-files approach (myfaces-faces-plugin), I open the build project and modify an xml file to add the info using the special xml tags. I then run the plugin. I then refresh my eclipse project. I then alter the renderer to access the new property on the generated component class. Note that just looking at the base component class gives *no* info about what properties that component has. With the doc-annotation approach (myfaces-builder-plugin), I open the normal tomahawk project, and add an abstract getter method (perfectly normal java coding). I then add the appropriate annotation as a doc-annotation. I then modify my renderer (no need to run the code generator; I can write calls to the abstract method fine). And with the doc-annotation approach, looking at the component class shows clearly that it has that property. In addition: (a) the amount of info I need in the annotation is much less than I needed to add to the xml file because the plugin can use introspection on the abstract method declaration (b) javadoc comments attached to the method are used automatically in the .tld etc. Generally extending components by adding whole bucket of local property/getter/setter seems not right for me because it's meant to provide just another feature not used by many people. Wouldn't it be more cleaner to just use that property as attribute (in JSF api's speach): storing/using it from getAttributes() map? This way it would just be needed to generate TLD/Tag entries, no customization of component's code needed. Also renderer has full access to attributes map by default ;) Nice side-effect to this approach is eventual speeding-up processing by adding cache to getAttributes() MyFaces map: storing already resolved values in transient map to avoid multiple resolving during lifecycle. * Use case 2: I create a new tomahawk converter class. With the xml-files approach, I open the build project and create some new xml files. Then I write the converter class in the main code project. With the myfaces-builder-plugin approach, I open the main code project, add the class and add a couple of doc-annotations. Clearly 2nd option rules :D * Use case 3: I create a new project (eg commons widgets) With the xml-files approach, I need to create two maven modules, one for the code and one for the builder stuff. Somehow I need to get access to all the metadata defined by the core build project (??). I then need to create metadata files for my project that (somehow) add info about my new components. With the doc-annotation approach, I just create a project for my code, add the builder plugin to my pom, and add annotations to any of my converters/validators/components. Done. A question about properties inheritance accross components arise: i really think that having the same propetry handled by multiple components in hiearchy is bad (quite common in Tomahawk). Also the Tomahawk code should use consistent way in components and tags inheritances. There should be a way to filter already defined properties in either approach. * Use case 4: A JSF newbie browses the myfaces-impl code. With the xml-files approach, he needs to also browse the xml files in the build project or alternatively browse the generated code to get any idea of how things work. With the doc-annotation approach, the annotations are there for him
[jira] Created: (TOMAHAWK-1214) allow to process form submits in a queue for high-speed input handling
allow to process form submits in a queue for high-speed input handling -- Key: TOMAHAWK-1214 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1214 Project: MyFaces Tomahawk Issue Type: New Feature Components: PPRPanelGroup Reporter: Mario Ivankovits Assignee: Ernst Fastl Enhance the PPR stuff in a way which allows to process form input asynchron in a queue for high-speed input handling. Probably by adding a new attribute to the PPRPanelGroup called "queued=true|false". With "true" the form data should be collected and held in a queue on client side. The client then checks that queue at given intervalls (queueCheckInterval=) if there is data in the queue and transmit that data to the server like a normal ppr request. Between each transmit a queueWaitInterval= should be waited. A status component (queueShowStatus=true|false) should show the success of each transmit. A client side javascript should be used to extract the status text information from the form data (queueShowStatusInfoBuilder=javascript-method-name(formData)) The PprPanelGroup should also be enhanced to being able to point to the messages component (messages=component-id) the queueStatus information should then be able to visualize that text and show e.g. a red-cross if there were errors (=messages) For this first version the status info can be a simple table created client-side using some css to allow to format it according to the application skin. A simple table with two columns status-info|return-visualization status-info is the text returned by the queueShowStatusInfoBuilder javascript method and return-visualization might be an icon. Only waiting requests and those with errors should be shown, correctly finished requests can be removed from the list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Tomahawk] Commit of component generation and 1.2 modules to trunk
Hi! > Hi, I like the approach. I am not very keen in "annotated" javadocs > (which is error prone IMO) but that is just fine and I would say a > better alternative to the XMLs (which are rather error prone too). > However, it would be nice to have the builder library generic enough > so we could use javadocs now and later have an alternative that uses > real JDK5 annotations for whoever prefers that approach. Same for me! > Thanks for the good work! +1 I like what Simon did too. I hope we can switch over to that soon. Ciao, Mario
Re: [Tomahawk] Commit of component generation and 1.2 modules to trunk
Hi, I like the approach. I am not very keen in "annotated" javadocs (which is error prone IMO) but that is just fine and I would say a better alternative to the XMLs (which are rather error prone too). However, it would be nice to have the builder library generic enough so we could use javadocs now and later have an alternative that uses real JDK5 annotations for whoever prefers that approach. Thanks for the good work! Bruno On 18/03/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Leonardo Uribe schrieb: > > > > > On Mon, Mar 17, 2008 at 6:05 PM, Andrew Robinson > <[EMAIL PROTECTED]> wrote: > > > > > http://wiki.apache.org/myfaces/MyfacesBuilderPlugin > > > > Is this supposed to be a solution to the code replacement? I don't > > recall any vote to achieve a resolution on how to go about the code > > generation. From what this looks like, it looks worse than the > current > > trinidad plugin. Embedding data in javadoc is really awful IMO. > > > > Or am I mistaken and this is just the tomahawk code builder? > > > > > > This wiki is the idea that Simon proposed for code generation in a > more concrete presentation based on the comments on the mailing list and > the starting code proposed on. > > > > > > https://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/branches/skitching > > > > Actually, I have worked a lot with myfaces-faces-plugin (older > trinidad build), I have full component generation for tomahawk 1.1 and > 1.2 ready for commit, and really I think that myfaces-faces-plugin is a > great tool (clear wiki, easy to understand and make it work, but > sometimes a little bit complex doing uncommon tasks). If it was my > decision, I will continue using myfaces-faces-plugin, commit tomahawk, > upgrade components from sandbox and release. > > > > It's clear that all solutions proposed for this issue (Code > Generation) sucks more or less. You're right. There is not a vote about > what should be the direction to take yet, but it's unclear how to manage > this (at least I don't know what to do in this case when some developers > thinks very different). > > > > suggestions about what to do are most welcome > > > The myfaces-builder-plugin stuff is an experiment/proof-of-concept at > the current time, That's why the code is in a "branches" directory. No > vote has been taken on using this approach; it was necessary to show > that this would work before calling a vote to make a choice between this > and the myfaces-faces-plugin (formerly trinidad-faces-plugin) approach. > > But there is enough concrete info there now (particularly thanks to > Leonardo's new wiki pages) for us to have a discussion. It's clear that > the approach will work; now the community needs to say which approach > they think is the most productive for the future. > > I would personally like to see this used for all projects: core1.1, > core1.2, tomahawk, commons and eventually trinidad too. I certainly see > no reason why the myfaces-builder-plugin approach cannot be used for > trinidad. It's just a matter of extending the "model" classes that hold > the metadata. And I see no theoretical reason why the existing .xml > files in the build project could not even be used as input to the > myfaces-builder-plugin (ie as an alternative to doc comments). Note that > the reverse is not true: there is no easy way to use doc comments to > feed metadata into the myfaces-faces-plugin, because that is really > seriously hard-wired to assume that xml files are its input. > > But the most important thing to me *is* getting away from the "build > project with lots of xml files" approach. > > == > > * Use case 1: > > I want to extend the t:inputDate component to add a property to a > component, and alter the renderer to use that property. > > With the xml-files approach (myfaces-faces-plugin), I open the build > project and modify an xml file to add the info using the special xml > tags. I then run the plugin. I then refresh my eclipse project. I then > alter the renderer to access the new property on the generated component > class. Note that just looking at the base component class gives *no* > info about what properties that component has. > > With the doc-annotation approach (myfaces-builder-plugin), I open the > normal tomahawk project, and add an abstract getter method (perfectly > normal java coding). I then add the appropriate annotation as a > doc-annotation. I then modify my renderer (no need to run the code > generator; I can write calls to the abstract method fine). > > And with the doc-annotation approach, looking at the component class > shows clearly that it has that property. In addition: > (a) the amount of info I need in the annotation is much less than I > needed to add to the xml file because the plugin can use introspection > on the abstract method declaration > (b) javadoc comments attached to the method are used automatically in > the .tld etc. > > * Use case 2: > > I create a new tomahawk conve
[jira] Created: (TRINIDAD-1012) SKinning for PanelPopup trigger
SKinning for PanelPopup trigger --- Key: TRINIDAD-1012 URL: https://issues.apache.org/jira/browse/TRINIDAD-1012 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.0.7-core Reporter: Tomas Havelka Fix For: 1.0.8-core When rendering panelPopup component trigger facet, renderer wraps content of this facet with link (for click triggerType) and sets its class name OraLink. This skin should be part of component skin selector like for example af|panelPopup::trigger to allow skin this component fragment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Tomahawk] Commit of component generation and 1.2 modules to trunk
Leonardo Uribe schrieb: > > On Mon, Mar 17, 2008 at 6:05 PM, Andrew Robinson <[EMAIL PROTECTED]> wrote: > > > http://wiki.apache.org/myfaces/MyfacesBuilderPlugin > > Is this supposed to be a solution to the code replacement? I don't > recall any vote to achieve a resolution on how to go about the code > generation. From what this looks like, it looks worse than the current > trinidad plugin. Embedding data in javadoc is really awful IMO. > > Or am I mistaken and this is just the tomahawk code builder? > > > This wiki is the idea that Simon proposed for code generation in a more concrete presentation based on the comments on the mailing list and the starting code proposed on. > > https://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/branches/skitching > > Actually, I have worked a lot with myfaces-faces-plugin (older trinidad build), I have full component generation for tomahawk 1.1 and 1.2 ready for commit, and really I think that myfaces-faces-plugin is a great tool (clear wiki, easy to understand and make it work, but sometimes a little bit complex doing uncommon tasks). If it was my decision, I will continue using myfaces-faces-plugin, commit tomahawk, upgrade components from sandbox and release. > > It's clear that all solutions proposed for this issue (Code Generation) sucks more or less. You're right. There is not a vote about what should be the direction to take yet, but it's unclear how to manage this (at least I don't know what to do in this case when some developers thinks very different). > > suggestions about what to do are most welcome The myfaces-builder-plugin stuff is an experiment/proof-of-concept at the current time, That's why the code is in a "branches" directory. No vote has been taken on using this approach; it was necessary to show that this would work before calling a vote to make a choice between this and the myfaces-faces-plugin (formerly trinidad-faces-plugin) approach. But there is enough concrete info there now (particularly thanks to Leonardo's new wiki pages) for us to have a discussion. It's clear that the approach will work; now the community needs to say which approach they think is the most productive for the future. I would personally like to see this used for all projects: core1.1, core1.2, tomahawk, commons and eventually trinidad too. I certainly see no reason why the myfaces-builder-plugin approach cannot be used for trinidad. It's just a matter of extending the "model" classes that hold the metadata. And I see no theoretical reason why the existing .xml files in the build project could not even be used as input to the myfaces-builder-plugin (ie as an alternative to doc comments). Note that the reverse is not true: there is no easy way to use doc comments to feed metadata into the myfaces-faces-plugin, because that is really seriously hard-wired to assume that xml files are its input. But the most important thing to me *is* getting away from the "build project with lots of xml files" approach. == * Use case 1: I want to extend the t:inputDate component to add a property to a component, and alter the renderer to use that property. With the xml-files approach (myfaces-faces-plugin), I open the build project and modify an xml file to add the info using the special xml tags. I then run the plugin. I then refresh my eclipse project. I then alter the renderer to access the new property on the generated component class. Note that just looking at the base component class gives *no* info about what properties that component has. With the doc-annotation approach (myfaces-builder-plugin), I open the normal tomahawk project, and add an abstract getter method (perfectly normal java coding). I then add the appropriate annotation as a doc-annotation. I then modify my renderer (no need to run the code generator; I can write calls to the abstract method fine). And with the doc-annotation approach, looking at the component class shows clearly that it has that property. In addition: (a) the amount of info I need in the annotation is much less than I needed to add to the xml file because the plugin can use introspection on the abstract method declaration (b) javadoc comments attached to the method are used automatically in the .tld etc. * Use case 2: I create a new tomahawk converter class. With the xml-files approach, I open the build project and create some new xml files. Then I write the converter class in the main code project. With the myfaces-builder-plugin approach, I open the main code project, add the class and add a couple of doc-annotations. * Use case 3: I create a new project (eg commons widgets) With the xml-files approach, I need to create two maven modules, one for the code and one for the builder stuff. Somehow I need to get access to all the metadata defined by the core build project (??). I then need to create metadata files for my project that (somehow) add info about my new components. With the doc-annotation approach
