[jira] Commented: (MYFACES-1976) Enhance build process, unpacking shared only when a release occur and use a dependency to shared instead

[Leonardo Uribe (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635941#action_12635941
 ] 

Leonardo Uribe commented on MYFACES-1976:
-

After checking this issue in deep (and do some work on bugs related to shared) 
the big reasons about why do that was clear (I didn't remember why do this).

 The actual behavior unpack shared sources and .class files on myfaces, so when 
the IDE open the project (for example using eclipse), the developer can see a 
source path called shared_sources. If it was a dependency only on snapshot 
build, when someone wants to see where this code comes from he/she see the 
shared dependency and for modifications goes to shared-impl project and then to 
shared-code (where the real code is). Do this makes easier to the user where 
the code comes from.

 Also, when a developer is running an app using maven jetty plugin, if a change 
in shared is done, it is necessary to compile shared-core, shared-impl and 
myfaces impl (because the code needs to be unpacked again for include the 
change). If we have a dependency only on snapshot build instead unpack the 
code, just a compile on shared core and impl it is necessary to check the 
change, so it makes a little bit faster the development.

 The only drawback doing this is that the release manager must compile the 
sources before release adding the property -DperformRelease=true, but since it 
is not a very common task it is ok.

If no objections, I'll commit the necessary changes on myfaces core 1.1 and 1.2.



> Enhance build process, unpacking shared only when a release occur and use a 
> dependency to shared instead
> 
>
> Key: MYFACES-1976
> URL: https://issues.apache.org/jira/browse/MYFACES-1976
> Project: MyFaces Core
>  Issue Type: Task
>Reporter: Leonardo Uribe
> Attachments: MYFACES-1976-jsf11.patch
>
>
> It could be good use maven profiles to unpack shared sources and add to 
> myfaces core impl jar only when a release occur, and on snapshot version use 
> a dependency to shared jar instead.

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

Re: Thoughts on Trinidad

[Leonardo Uribe]

On Mon, Sep 29, 2008 at 12:54 PM, Matthias Wessendorf <[EMAIL PROTECTED]>wrote:

> also, the sandbox renderer approach sounds good so far.
> However, you should ensure we don't break a lot of things
>
> -Matthias
>
> On Mon, Sep 29, 2008 at 7:53 PM, Matthias Wessendorf <[EMAIL PROTECTED]>
> wrote:
> > On Mon, Sep 29, 2008 at 7:46 PM, Simon Lessard
> > <[EMAIL PROTECTED]> wrote:
> >> Hi Andrew,
> >>
> >> Yes I think Adam made a wiki for UIXNode conversion during the time of
> >> incubation, I'll have to look for the link.
> >>
> >> As for JSF 2.0 adoption, I would say 2 years after the specification
> release
> >> which is... not so soon. Implementation will start before that though
> and I
> >> think it's what important for our side. So personally I would say clean
> up
> >> the code... a lot as not only UIXNode need it, but wait for JSF 2.0 so
> that
> >
> > +1 on an earlier clean-up than to wait on JSF 2 to do the clean-up.
> >
> >> our cleaning reflect JSF 2.0 changes, but working in a 1.2 environment.
> I
> >> gully agree about 1.0 trunk, I have no motivation at all about it.
> >
> > yes. And with the advent of Trinidad2/JSF2 we also should send Trinidad
> 1.2
> > to maintaining stage (sure some bug fixes don't hurt)
> >>
> >>
> >> Regards,
> >>
> >> ~ Simon
> >>
> >>
> >>
> >> On Mon, Sep 29, 2008 at 1:40 PM, Andrew Robinson
> >> <[EMAIL PROTECTED]> wrote:
> >>>
> >>> > However, as Matthias pointed out, JSF 2.0 standardize Trinidad's
> >>> > principal
> >>> > core features namely PPR and Resource handling and hopefully skinning
> >>> > too.
> >>> > Under such circumstances, I feel that we should wait for 2.0 to be
> >>> > cemented
> >>> > before going through a massive refactoring of some of the old and
> >>> > twisted
> >>> > code parts so that the refactored design is fully compatible with
> 1.2,
> >>> > but
> >>> > using 2.0 concept to make the upgrade to 2.0 easier imho.
> >>>
> >>> Although those are really good concerns, I wonder how long it will
> >>> take JSF2 to be adopted. It seems like many are even reluctant to
> >>> adopt 1.2. So I wonder if it is still worth it for us to make an
> >>> effort to at least clean up the 1.2 trunk? (I did not mention the 1.0
> >>> trunk as I seem to have lost my desire to maintain the JSF 1.1 code
> >>> myself)
> >>>
> >>> I guess it comes down to time and desire. I worry about the UIXNode
> >>> conversion as I don't yet fully understand that code enough to feel
> >>> comfortable porting it without missing things. I guess I could create
> >>> sandbox renderers for the components, then if they look complete, we
> >>> could promote them & replace the UIXNode ones at that time. Is there a
> >>> WIKI page that I missed that talks about how to convert these guys or
> >>> about any of the UIXNode architecture?
> >>>
> >>> -Andrew
> >>
> >>
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>

I would like to see two things about trinidad code (it is just my personal
opinion about it):

1. Modify trinidad maven-faces-plugin so it adds myfaces-builder-plugin
annotations when rendering code, so a generated myfaces-metadata.xml exists
and make trinidad sandbox components more easier (using
myfaces-builder-plugin instead). This change does not affect any
functionality. Actually create custom trinidad components it is not a very
easy task.

2. Separate skin related api so other myfaces projects can use it (for
example tomahawk but this api needs some cleanup first).

regards

Leonardo Uribe

[jira] Resolved: (MYFACES-1978) Remove org.apache.myfaces.portlet from JSF 2.0 branch, because it has no use anymore

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-1978.
-

   Resolution: Fixed
Fix Version/s: 2.0.0-alpha
 Assignee: Leonardo Uribe

> Remove org.apache.myfaces.portlet from JSF 2.0 branch, because it has no use 
> anymore
> 
>
> Key: MYFACES-1978
> URL: https://issues.apache.org/jira/browse/MYFACES-1978
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.0.0-alpha
>
>
> This api inside myfaces-impl was replaced by portlet bridge project and does 
> not work anymore on 1.2,  so it should be removed since this version has not 
> been released yet

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

[jira] Resolved: (TOMAHAWK-1183) onFocus and some html properties rendered twice or not rendered (inputCalendar setfocus not working)

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved TOMAHAWK-1183.
--

   Resolution: Fixed
Fix Version/s: 1.1.8-SNAPSHOT
 Assignee: Leonardo Uribe

thanks to Paul Rivera for provide us this patch

> onFocus and some html properties rendered twice or not rendered 
> (inputCalendar setfocus not working)
> 
>
> Key: TOMAHAWK-1183
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1183
> Project: MyFaces Tomahawk
>  Issue Type: Bug
>Affects Versions: 1.1.6
> Environment: windows xp
>Reporter: richard lee
>Assignee: Leonardo Uribe
> Fix For: 1.1.8-SNAPSHOT
>
> Attachments: myfaces-shared-2.0.9.patch, myfaces-shared-3.0.4.patch, 
> testcases.rar, testcases2.rar, testExampleOverMyfacesImpl.patch, 
> tomahawk-1.1.7.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The inputCalendar tag / component is not rendering javascript entered for the 
> setfocus property. I'm attempting to add some custom javascript to the 
> setfocus of an inputcalendar to be run when the user clicks in the input box 
> associated with the calendar, but this is being ignored during the redering 
> of the input box. The only javascript that gets rendered is the "standard" 
> javascript , i.e. onfocus="selectText('null', 'con9n')".
> I believe the issue is in HtmlTextHelpRenderer:
> if(isSelectText(component))
> {
> HtmlRendererUtils.renderHTMLAttributes(writer, component,
>
> HTML.INPUT_PASSTHROUGH_ATTRIBUTES_WITHOUT_DISABLED_AND_ONFOCUS_AND_ONCLICK);
> writer.writeAttribute(HTML.ONFOCUS_ATTR,
>   
> HtmlInputTextHelp.JS_FUNCTION_SELECT_TEXT + "('" +
>   getHelpText(component) + "', '" + id 
> +"')", null);
> writer.writeAttribute(HTML.ONCLICK_ATTR,
>   
> HtmlInputTextHelp.JS_FUNCTION_SELECT_TEXT + "('" +
>   getHelpText(component) + "', '" + id 
> +"')", null);
> }
> when writing out the HTML.ONFOCUS_ATTR is should write out any user specified 
> onfocus attributes as well as the standard ones.

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

[jira] Commented: (TOMAHAWK-1343) roundedDiv does not render passthrough attributes

[Leonardo Uribe (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOMAHAWK-1343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635895#action_12635895
 ] 

Leonardo Uribe commented on TOMAHAWK-1343:
--

I have committed the solution proposed by paul, since it seems to be fine when 
it is used div, but for table layout a solution is still required

> roundedDiv does not render passthrough attributes
> -
>
> Key: TOMAHAWK-1343
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1343
> Project: MyFaces Tomahawk
>  Issue Type: Bug
>Affects Versions: 1.1.8-SNAPSHOT
> Environment: myfaces 1.1.7-snapshot
> tomahawk 1.1.8-snapshot
> tomahawk sandbox 1.1.8-snapshot
> tomcat 6.0.16
> java 1.6.0
>Reporter: Paul Rivera
>Assignee: Andrew Robinson
> Attachments: HtmlRoundedDivRenderer.patch
>
>
> Except for style and styleClass, most of the passthrough attributes of 
> roundedDiv declared in the myfaces_sandbox.tld do not get rendered:
> Dir, lang, title,onclick, ondblclick, onkeydown, onkeypress, onkeyup, 
> onmousedown, onmousemove, onmouseout, onmouseover, onmouseup.
> Given this jsf code:
>  backgroundColor="#00"
>   borderColor="#5599AA"
>   borderWidth="1"
>   color="#559911"
>   radius="100"
>   layout="table"
>   onmouseover="alert('mouseover event');"
>   onclick="alert('click event');"
>   style="mystyle"
>   styleClass="mystyleClass">
>   
>   
> passthrough attributes onmouseover and onclick do not get rendered.

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

[jira] Resolved: (TOMAHAWK-1342) passwordStrength does not render passthrough attributes

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved TOMAHAWK-1342.
--

   Resolution: Fixed
Fix Version/s: 1.1.8-SNAPSHOT
 Assignee: Leonardo Uribe

thanks to Paul Rivera for provide this patch

> passwordStrength does not render passthrough attributes
> ---
>
> Key: TOMAHAWK-1342
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1342
> Project: MyFaces Tomahawk
>  Issue Type: Bug
>Affects Versions: 1.1.8-SNAPSHOT
> Environment: tomcat 6.0.16
> java 1.6.0
> tomahawk 1.1.8-snapshot
> tomahawk sandbox 1.1.8-snapshot
> myfaces 1.1.7-snapshot
>Reporter: Paul Rivera
>Assignee: Leonardo Uribe
> Fix For: 1.1.8-SNAPSHOT
>
> Attachments: PasswordStrengthRenderer.patch
>
>
> passwordStrength doesn't seem to be rendering pass through attributes 
> declared in myfaces_sandbox.tld like:
> Accesskey, dir, lang, title, onfocus, onblur, ondblclick, onkeydown, 
> onkeypress, onkeyup, onmousedown, onmousemove, onmouseout, onmouseover, 
> onmouseup, style, styleClass, and tabindex.
> given a jsf page:
>   
>  textStrengthDescriptions="Very Poor;Weak;Average;Strong;Excellent" 
> strengthIndicatorType="text"
>   style="color: orange;" onfocus="myfocusFunc();" onkeyup="mykeyupfunc();"
>   onblur="myOnblurFunc();"/>
> this is what gets rendered:
>   Password:
>   var myfaces__idJsp1 = new 
> org.apache.myfaces.passwordStrength();window.addEventListener('load',function()
>  {myfaces__idJsp1.startUpPasswordStrength('_idJsp1indicatorMessage'); }, 
> false); name="_idJsp1" value="" 
> onkeyup="myfaces__idJsp1.updateStatusValue('_idJsp1',10, 'Strength : ', 'Very 
> Poor;Weak;Average;Strong;Excellent', '_idJsp1indicatorMessage', 
> '_idJsp1leftCharsMessage', 'text', '_idJsp1_PROGRESSBAR', 'true', 'characters 
> are left', 'false', 'A1', 
> '50');myfaces__idJsp1.show('_idJsp1indicatorMessage');"  
> onblur="myfaces__idJsp1.hide('_idJsp1indicatorMessage');myfaces__idJsp1.hide('_idJsp1leftCharsMessage');"
>  /> class="org_apache_myfaces_passwordStrength_progress_indicatorMessage">  id="_idJsp1leftCharsMessage">
> not all of the attributes I pass in s:passwordStrength gets rendered.

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

[jira] Resolved: (TOMAHAWK-1337) swapImage renders onmouseover and onmouseout twice

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved TOMAHAWK-1337.
--

   Resolution: Fixed
Fix Version/s: 1.1.8-SNAPSHOT
 Assignee: Leonardo Uribe

thanks to Paul Rivera for provide us this patch

> swapImage renders onmouseover and onmouseout twice
> --
>
> Key: TOMAHAWK-1337
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1337
> Project: MyFaces Tomahawk
>  Issue Type: Bug
>Affects Versions: 1.1.8-SNAPSHOT
> Environment: tomcat 6.0.16
> java 1.6.0
> tomahawk 1.1.8-SNAPSHOT
>Reporter: Paul Rivera
>Assignee: Leonardo Uribe
>Priority: Minor
> Fix For: 1.1.8-SNAPSHOT
>
> Attachments: HtmlSwapImageRenderer.patch, 
> shared-2.0.9-SNAPSHOT.patch, shared-3.0.5-SNAPSHOT.patch
>
>
> Here's what my page rendered for my swapImage:
>  onmouseover="SI_MM_swapImage('_idJsp0:foo','','/MYFACES11-Playground/images/feather.gif',1);"
>  onmouseout="SI_MM_swapImgRestore();" border="Integer.MIN_VALUE" 
> onmouseover="alert('onmouseover2');" onmouseout="alert('onmouseout2');" />
> As you can see, onmouseover and onmouseout are rendered twice.  In this case, 
> alert('onmouseover2') and alert('onmouseout2') never get executed.
> Both onmouseover and onmouseout attributes are not declared as attributes of 
> swapImage tag in tomahawk.tld.  You can only replicate this bug if you bind 
> your swapImage object to a bean.  Here's my bean:
> public class SwapImageBean
> {
> private HtmlSwapImage swapImage;
> 
> public SwapImageBean() {
> swapImage = new HtmlSwapImage();
> swapImage.getAttributes().put(HTML.ONMOUSEOVER_ATTR, 
> "alert('onmouseover2');");
> swapImage.getAttributes().put(HTML.ONMOUSEOUT_ATTR, 
> "alert('onmouseout2');");
> }
> public HtmlSwapImage getSwapImage()
> {
> return swapImage;
> }
> public void setSwapImage(HtmlSwapImage swapImage)
> {
> this.swapImage = swapImage;
> }
> }

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

[jira] Resolved: (MYFACES-1981) outputLink does not render onfocus and onblur

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-1981.
-

   Resolution: Fixed
Fix Version/s: 1.1.7-SNAPSHOT
 Assignee: Leonardo Uribe

Thanks to Paul Rivera for provide us this patch

> outputLink does not render onfocus and onblur
> -
>
> Key: MYFACES-1981
> URL: https://issues.apache.org/jira/browse/MYFACES-1981
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 1.1.7-SNAPSHOT
> Environment: tomcat 6.0.16
> java 1.6.0
> myfaces 1.1.7-snapshot
>Reporter: Paul Rivera
>Assignee: Leonardo Uribe
>Priority: Minor
> Fix For: 1.1.7-SNAPSHOT
>
> Attachments: myfaces-shared-2.0.9-snapshot.patch, 
> myfaces-shared-3.0.5-snapshot.patch
>
>
> onfocus and onblur are not rendered in outputLink.  Although, these 
> attributes are declared in the tld for the outputLink tag.  Here's my jsf 
> snippet:
> 
>   http://SomeURL"; onfocus="myfunc();" onblur="myfunc();" 
> onmouseover="myfunc();" >
> 
>   
> 
> And this is what gets rendered:
> http://SomeURL"; 
> onmouseover="myfunc();">Click Me

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

[jira] Updated: (TOMAHAWK-1306) Focus2 postback problem

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe updated TOMAHAWK-1306:
-

Resolution: Fixed
Status: Resolved  (was: Patch Available)

thanks to Paul Rivera for provide us with this patch

> Focus2 postback problem
> ---
>
> Key: TOMAHAWK-1306
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1306
> Project: MyFaces Tomahawk
>  Issue Type: Bug
>  Components: New Component
>Affects Versions: 1.1.7-SNAPSHOT
> Environment: myfaces-1.2.4-SNAPSHOT
> tomahawk-sandbox12-1.1.7-SNAPSHOT
> tomahawk12-1.1.7-SNAPSHOT
> Tomcat 6.0.16
>Reporter: Paul Rivera
> Fix For: 1.1.8-SNAPSHOT
>
> Attachments: focus2.HtmlFocusRenderer-2.patch, 
> focus2.HtmlFocusRenderer.patch, webapp-files.rar
>
>
> Below are the main use cases for Focus2:
> 1) if you first get to a page, the _first_ input field should be highlighted
> 2) if you post-back to a page and there is a validation-error, the
> first field with a validation error should be highlighted
> 3) if you change a value on a form (e.g. a drop-down) and this
> changing a value initiates a postback, you will want the next field
> highlighted after the field that initiated the post-back to be
> highlighted
> Here are some bugs I've found:
> I) Focus2 cannot distinguish a newly created view (user first enters the 
> webpage) from a postback (user does a submit and the same page gets loaded). 
> See the attached testValueAttr.jsp to replicate the bug.
> What happens is that if you have the following tag in your code:
> 
> Focus2 will give focus to the component succeeding mainForm:email.  In the 
> case of testValueAttr.jsp, it is mainForm:country. In the 
> focus2.HtmlFocusRenderer.getFocusForId(), it always assumes that it is a 
> postback.
> II) Focus2.HtmlFocusRenderer does not retrieve the submitted value in its 
> decode() method.  In the current implementation, HtmlFocusRenderer calls 
> super.decode(context, component). I've checked and found out that after this 
> line, the _submittedValue of the component is still null.  _submittedValue 
> should be the clientId of the currently focused input field maintained in a 
> hidden field in your user's browser and updated by javascript for each focus 
> event (See focus2.HtmlFocusRenderer.writeUpdateFocusScript()).  Please see 
> attached testPostBack.jsp to replicate the bug.  Use case 3 fails here.
> The patch will fix both these bugs.

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

[jira] Resolved: (MYFACES-1983) Implement JSF 2.0 logic at TODO #42

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-1983.
-

   Resolution: Fixed
Fix Version/s: 2.0.0-alpha

> Implement JSF 2.0 logic at TODO #42
> ---
>
> Key: MYFACES-1983
> URL: https://issues.apache.org/jira/browse/MYFACES-1983
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Simon Lessard
>Assignee: Leonardo Uribe
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> In class: org.apache.myfaces.application.ResourceHandlerImpl
> Implement: public boolean libraryExists(String libraryName)

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

[jira] Resolved: (MYFACES-1973) Implement JSF 2.0 logic at TODO #40

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-1973.
-

   Resolution: Fixed
Fix Version/s: 2.0.0-alpha

> Implement JSF 2.0 logic at TODO #40
> ---
>
> Key: MYFACES-1973
> URL: https://issues.apache.org/jira/browse/MYFACES-1973
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Simon Lessard
>Assignee: Leonardo Uribe
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> In class: org.apache.myfaces.application.ResourceHandlerImpl
> Implement: public boolean isResourceRequest(FacesContext context)

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

[jira] Resolved: (MYFACES-1969) Implement JSF 2.0 logic at TODO #36

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-1969.
-

   Resolution: Fixed
Fix Version/s: 2.0.0-alpha

> Implement JSF 2.0 logic at TODO #36
> ---
>
> Key: MYFACES-1969
> URL: https://issues.apache.org/jira/browse/MYFACES-1969
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Simon Lessard
>Assignee: Leonardo Uribe
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> In class: org.apache.myfaces.application.ResourceHandlerImpl
> Implement: public Resource createResource(String resourceName, String 
> libraryName)

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

[jira] Resolved: (MYFACES-1970) Implement JSF 2.0 logic at TODO #37

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-1970.
-

   Resolution: Fixed
Fix Version/s: 2.0.0-alpha

> Implement JSF 2.0 logic at TODO #37
> ---
>
> Key: MYFACES-1970
> URL: https://issues.apache.org/jira/browse/MYFACES-1970
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Simon Lessard
>Assignee: Leonardo Uribe
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> In class: org.apache.myfaces.application.ResourceHandlerImpl
> Implement: public Resource createResource(String resourceName, String 
> libraryName, String contentType)

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

[jira] Resolved: (MYFACES-1972) Implement JSF 2.0 logic at TODO #39

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-1972.
-

   Resolution: Fixed
Fix Version/s: 2.0.0-alpha

> Implement JSF 2.0 logic at TODO #39
> ---
>
> Key: MYFACES-1972
> URL: https://issues.apache.org/jira/browse/MYFACES-1972
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Simon Lessard
>Assignee: Leonardo Uribe
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> In class: org.apache.myfaces.application.ResourceHandlerImpl
> Implement: public void handleResourceRequest(FacesContext context)

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

[jira] Resolved: (MYFACES-1971) Implement JSF 2.0 logic at TODO #38

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-1971.
-

   Resolution: Fixed
Fix Version/s: 2.0.0-alpha

> Implement JSF 2.0 logic at TODO #38
> ---
>
> Key: MYFACES-1971
> URL: https://issues.apache.org/jira/browse/MYFACES-1971
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Simon Lessard
>Assignee: Leonardo Uribe
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> In class: org.apache.myfaces.application.ResourceHandlerImpl
> Implement: public String getRendererTypeForResourceName(String resourceName)

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

Re: State Saving in MyFaces Core 1.2

[Scott O'Bryan]

Correction, Cagatay found this.  Sigh.  It's been one of those days.

Scott

Scott O'Bryan wrote:

Hey guys,

We tracked down the problem that Cathay discovered with the Myfaces 
Portlet Bridge Alpha-3 release and it seems to be related to how 
MyFaces does it's state saving.  As you may or may not know, because 
of some servlet dependencies in both the R.I for JSF 1.2 and MyFaces, 
the Bridge needs to implement it's own ViewHandler.  Pretty much the 
only functionality of this view handler is replacing the token which 
is saved in the response with the actual view state key (or whatnot).  
The bridge has code to handle the ViewState token for both the R.I. 
and MyFaces, and other JSF implementations can configure a token to 
use for the token replacement.


The problem we have is that MyFaces only saves the token when the 
state saving method is set to client.  Server and Javascript state 
saving just save the tokens they use right up front.  This leaves the 
Bridge's view handler with no discernable token and we log a warning 
saying the token can't be found and should be configured.


Looking at it, the logic in MyFaces makes sense to me, because if we 
have a token which represents state on the server, there is no reason 
this should need to change.  But it does kind of mess up the bridge's 
ability to find the right token in it's ViewHandler and as far as I 
can tell there is no real performance gain to doing things this way 
since pretty much the whole set of code is executed anyway.


Is there any problem with simply saving the state token every time and 
then at the end replacing the token with the view-state whether that 
be a key to a server-side state, a javascript variable, or a 
client-side state?


Scott

State Saving in MyFaces Core 1.2

[Scott O'Bryan]

Hey guys,

We tracked down the problem that Cathay discovered with the Myfaces 
Portlet Bridge Alpha-3 release and it seems to be related to how MyFaces 
does it's state saving.  As you may or may not know, because of some 
servlet dependencies in both the R.I for JSF 1.2 and MyFaces, the Bridge 
needs to implement it's own ViewHandler.  Pretty much the only 
functionality of this view handler is replacing the token which is saved 
in the response with the actual view state key (or whatnot).  The bridge 
has code to handle the ViewState token for both the R.I. and MyFaces, 
and other JSF implementations can configure a token to use for the token 
replacement.


The problem we have is that MyFaces only saves the token when the state 
saving method is set to client.  Server and Javascript state saving just 
save the tokens they use right up front.  This leaves the Bridge's view 
handler with no discernable token and we log a warning saying the token 
can't be found and should be configured.


Looking at it, the logic in MyFaces makes sense to me, because if we 
have a token which represents state on the server, there is no reason 
this should need to change.  But it does kind of mess up the bridge's 
ability to find the right token in it's ViewHandler and as far as I can 
tell there is no real performance gain to doing things this way since 
pretty much the whole set of code is executed anyway.


Is there any problem with simply saving the state token every time and 
then at the end replacing the token with the view-state whether that be 
a key to a server-side state, a javascript variable, or a client-side state?


Scott

Re: MyFaces shared question

[Simon Lessard]

I'll go along that path then. I think I will be able to avoid putting
anything 2.0 specific methods in it.


Thanks,

~ Simon

On Tue, Sep 30, 2008 at 10:30 AM, Simon Kitching <[EMAIL PROTECTED]>wrote:

> Simon Lessard schrieb:
>
>> Hi Paul, Simon and others,
>>
>> I guess those are valid concerns, but I see one evolutivity problem, even
>> with a private copy. Let say you have:
>>
>> 1. Shared class A with method foo() in shared x.y.1
>> 2. Core 1.2.1 uses that method as well as Tomahawk 1.2.1
>> 3. For Core 1.2.2, a change is required to foo's contract, releasing
>> shared x.y.2. For now everything is good since Tomahawk has a private copy
>> of x.y.1
>> 4. Tomahawk 1.2.2 also need a change to foo's contract, but not the same
>> as Core 1.2.2 and furthermore excluding the changes needed so applying the
>> change to shared from x.y.1 base, causing a new release of shared x.y.3.
>> Still everything is fine.
>>
>> From that point onward though, foo method will have to get reverted back
>> and forth for both projects in order to include other fixes and
>> improvements, no?
>>
> Yep. So in that case either a method foo2() needs to be created, or a class
> A2. Hopefully that doesn't happen too often.
>
>>
>> As for the current structure, I'm not adamantly against it, so given we
>> keep it, do you think I shared rebranch it for 2.0 or try to use 3.0.x?
>>
> I would suggest using 3.0.x until you find that something just won't fit,
> and branch it then.
>
> I guess the danger with that is that you could add a bunch of code that
> only 2.0.x needs and then find you need to branch anyway, leaving a
> JSF1.2-specific "shared" version containing code that nothing is using. But
> the disadvantage of forking is obviously that patches need to be applied to
> multiple branches. Where's that crystal ball :-)
>
> Regards,
> Simon
>
>

Re: MyFaces shared question

[Simon Kitching]

Simon Lessard schrieb:

Hi Paul, Simon and others,

I guess those are valid concerns, but I see one evolutivity problem, 
even with a private copy. Let say you have:


1. Shared class A with method foo() in shared x.y.1
2. Core 1.2.1 uses that method as well as Tomahawk 1.2.1
3. For Core 1.2.2, a change is required to foo's contract, releasing 
shared x.y.2. For now everything is good since Tomahawk has a private 
copy of x.y.1
4. Tomahawk 1.2.2 also need a change to foo's contract, but not the 
same as Core 1.2.2 and furthermore excluding the changes needed so 
applying the change to shared from x.y.1 base, causing a new release 
of shared x.y.3. Still everything is fine.


From that point onward though, foo method will have to get reverted 
back and forth for both projects in order to include other fixes and 
improvements, no?
Yep. So in that case either a method foo2() needs to be created, or a 
class A2. Hopefully that doesn't happen too often.


As for the current structure, I'm not adamantly against it, so given 
we keep it, do you think I shared rebranch it for 2.0 or try to use 3.0.x?
I would suggest using 3.0.x until you find that something just won't 
fit, and branch it then.


I guess the danger with that is that you could add a bunch of code that 
only 2.0.x needs and then find you need to branch anyway, leaving a 
JSF1.2-specific "shared" version containing code that nothing is using. 
But the disadvantage of forking is obviously that patches need to be 
applied to multiple branches. Where's that crystal ball :-)


Regards,
Simon

Re: MyFaces shared question

[Simon Lessard]

Hi Paul, Simon and others,

I guess those are valid concerns, but I see one evolutivity problem, even
with a private copy. Let say you have:

1. Shared class A with method foo() in shared x.y.1
2. Core 1.2.1 uses that method as well as Tomahawk 1.2.1
3. For Core 1.2.2, a change is required to foo's contract, releasing shared
x.y.2. For now everything is good since Tomahawk has a private copy of x.y.1
4. Tomahawk 1.2.2 also need a change to foo's contract, but not the same as
Core 1.2.2 and furthermore excluding the changes needed so applying the
change to shared from x.y.1 base, causing a new release of shared x.y.3.
Still everything is fine.

>From that point onward though, foo method will have to get reverted back and
forth for both projects in order to include other fixes and improvements,
no?

As for the current structure, I'm not adamantly against it, so given we keep
it, do you think I shared rebranch it for 2.0 or try to use 3.0.x?


Regards,

~ Simon


On Tue, Sep 30, 2008 at 9:01 AM, Simon Kitching <[EMAIL PROTECTED]>wrote:

> That's a pretty good summary.
>
> The existing setup was created precisely because the old approach (a plain
> old shared jar that multiple projects depended on) was a major pain for the
> reasons listed by Paul below.
>
> Note that even with the existing setup, other projects can use the shared
> jar. They just use their own *copy* of it. The current approach of having
> the shared project create orchestra/tomahawk/shared flavours of itself is
> not optimal; really there should be one shared jar, and other projects
> should "copy-and-repackage" as needed. However that's a little tricky to set
> up and hasn't been high on anyone's todo list as the current approach works.
>
> The fact that when core, tomahawk and orchestra are all used in a single
> project then there are 3 copies of the shared classes in memory is really
> not significant. I cannot imagine anyone using myfaces in a mobile java
> system for example. One con of the existing approach that was not listed is
> debugging: it is a minor nuisance to make sure that your breakpoints in
> shared code is actually on the one in the appropriate package. But that
> isn't terribly hard.
>
> Simon, imagine if there was one jar. Before releasing core-2.0.x would you
> really retest tomahawk and orchestra to see if the new version of shared
> breaks them? And do you really trust tomahawk and orchestra release managers
> to thoroughly test myfaces-core releases against a new shared release before
> it is made? With the current setup, such testing is not so important; a
> mistake can break snapshot builds but never production deployments because
> the shared code changes don't get "forced" onto other projects. This is
> particularly important given the pretty poor unit-test-coverage percentage
> on myfaces projects.
>
> The binary-compatibility issue below is also very important. A shared jar
> means binary-incompatible changes in shared become impossible, forever.
> That's pretty scary. With the "private copy" approach an incompatible change
> still needs agreement by all projects (svn trunk on each project needs to be
> updated to match) but it is possible.
>
> And handling user bugreports becomes exponentially harder too when they can
> have various versions of shared lib in their classpath. Yecch.
>
> I would be very reluctant to see a return to a plain jar. I don't want to
> have to be paranoid about code changes breaking core or tomahawk production
> releases when I just want to fix an orchestra bug that is due to something
> in shared.
>
> Regards,
> Simon K.
>
> Paul Rivera schrieb:
>
>> Hi Simon,
>>
>> There's another discussion on this here:
>> http://www.mail-archive.com/dev@myfaces.apache.org/msg32495.html
>>
>> These are basically the main points of the discussion:
>>
>> pros of an external dependency
>>  * no duplicate code
>>  * other projects can use it
>>
>> cons of an external dependency
>>  * fundamental projects (core, trinidad) would then depend on an extra jar
>>  * placing code shared between projects into a normal jar means that
>>   upgrading one project may force the shared jar to be updated,
>>   which can break the other project - unless we enforce 100% binary and
>> semantic
>>   compatibility between releases of that jar.
>>
>> I hope this helps you.
>>
>> I'm a fairly new member of this community.  Perhaps someone else can give
>> a deeper insight on this?
>>
>> Best Regards,
>> Paul Rivera
>>
>> --- On *Mon, 9/29/08, Simon Lessard /<[EMAIL PROTECTED]>/* wrote:
>>
>>From: Simon Lessard <[EMAIL PROTECTED]>
>>Subject: Re: MyFaces shared question
>>To: "MyFaces Development" ,
>>[EMAIL PROTECTED]
>>Date: Monday, September 29, 2008, 8:43 AM
>>
>>Hi Paul,
>>
>>Thanks for the link, it makes the whole thing clearer. However, is
>>that point still debatable? I quite disagree about the conclusion
>>about forcing the upgrade of the core if you upgrade Tomahawk.
>>Upgrad

Re: MyFaces shared question

[Simon Kitching]

That's a pretty good summary.

The existing setup was created precisely because the old approach (a 
plain old shared jar that multiple projects depended on) was a major 
pain for the reasons listed by Paul below.


Note that even with the existing setup, other projects can use the 
shared jar. They just use their own *copy* of it. The current approach 
of having the shared project create orchestra/tomahawk/shared flavours 
of itself is not optimal; really there should be one shared jar, and 
other projects should "copy-and-repackage" as needed. However that's a 
little tricky to set up and hasn't been high on anyone's todo list as 
the current approach works.


The fact that when core, tomahawk and orchestra are all used in a single 
project then there are 3 copies of the shared classes in memory is 
really not significant. I cannot imagine anyone using myfaces in a 
mobile java system for example. One con of the existing approach that 
was not listed is debugging: it is a minor nuisance to make sure that 
your breakpoints in shared code is actually on the one in the 
appropriate package. But that isn't terribly hard.


Simon, imagine if there was one jar. Before releasing core-2.0.x would 
you really retest tomahawk and orchestra to see if the new version of 
shared breaks them? And do you really trust tomahawk and orchestra 
release managers to thoroughly test myfaces-core releases against a new 
shared release before it is made? With the current setup, such testing 
is not so important; a mistake can break snapshot builds but never 
production deployments because the shared code changes don't get 
"forced" onto other projects. This is particularly important given the 
pretty poor unit-test-coverage percentage on myfaces projects.


The binary-compatibility issue below is also very important. A shared 
jar means binary-incompatible changes in shared become impossible, 
forever. That's pretty scary. With the "private copy" approach an 
incompatible change still needs agreement by all projects (svn trunk on 
each project needs to be updated to match) but it is possible.


And handling user bugreports becomes exponentially harder too when they 
can have various versions of shared lib in their classpath. Yecch.


I would be very reluctant to see a return to a plain jar. I don't want 
to have to be paranoid about code changes breaking core or tomahawk 
production releases when I just want to fix an orchestra bug that is due 
to something in shared.


Regards,
Simon K.

Paul Rivera schrieb:

Hi Simon,

There's another discussion on this here:
http://www.mail-archive.com/dev@myfaces.apache.org/msg32495.html

These are basically the main points of the discussion:

pros of an external dependency
  * no duplicate code
  * other projects can use it

cons of an external dependency
  * fundamental projects (core, trinidad) would then depend on an 
extra jar

  * placing code shared between projects into a normal jar means that
   upgrading one project may force the shared jar to be updated,
   which can break the other project - unless we enforce 100% binary 
and semantic

   compatibility between releases of that jar.

I hope this helps you.

I'm a fairly new member of this community.  Perhaps someone else can 
give a deeper insight on this?


Best Regards,
Paul Rivera

--- On *Mon, 9/29/08, Simon Lessard /<[EMAIL PROTECTED]>/* wrote:

From: Simon Lessard <[EMAIL PROTECTED]>
Subject: Re: MyFaces shared question
To: "MyFaces Development" ,
[EMAIL PROTECTED]
Date: Monday, September 29, 2008, 8:43 AM

Hi Paul,

Thanks for the link, it makes the whole thing clearer. However, is
that point still debatable? I quite disagree about the conclusion
about forcing the upgrade of the core if you upgrade Tomahawk.
Upgrading Tomahawk might force the upgrade of shared, but not
necessarily if the former doesn't depend on a latest change to
shared. Furthermore you don't need to upgrade core if you upgrade
shared if the latter enforce backward compatibility.

Personally I must admit that I don't really like the preprocessing
since it means having two of the same class on the classpath but
in different packages if you use both core and Tomahawk.


Regards,

~ Simon

On Mon, Sep 29, 2008 at 12:10 AM, Paul Rivera
<[EMAIL PROTECTED] > wrote:

Hi Simon,

I think this link explains it best:
http://wiki.apache.org/myfaces/Source_Code_Packaging

Best Regards,
Paul Rivera

--- On *Sun, 9/28/08, Simon Lessard
/<[EMAIL PROTECTED]
>/* wrote:

From: Simon Lessard <[EMAIL PROTECTED]
>
Subject: MyFaces shared question
To: "MyFaces-Devs" mailto:dev@myfaces.apache.org>>
Date: Sunday, September 28, 2008, 7:38 AM


Hi all,

Anyone knows why myfaces-sh

Re: MyFaces shared question

[Paul Rivera]

Hi Simon,

There's another discussion on this here:
http://www.mail-archive.com/dev@myfaces.apache.org/msg32495.html

These are basically the main points of the discussion:

pros of an external dependency
  * no duplicate code
  * other projects can use it

cons of an external dependency
  * fundamental projects (core, trinidad) would then depend on an extra jar
  * placing code shared between projects into a normal jar means that
   upgrading one project may force the shared jar to be updated,
   which can break the other project - unless we enforce 100% binary and 
semantic
   compatibility between releases of that jar.

I hope this helps you.

I'm a fairly new member of this community.  Perhaps someone else can give a 
deeper insight on this?

Best Regards,
Paul Rivera

--- On Mon, 9/29/08, Simon Lessard <[EMAIL PROTECTED]> wrote:
From: Simon Lessard <[EMAIL PROTECTED]>
Subject: Re: MyFaces shared question
To: "MyFaces Development" , [EMAIL PROTECTED]
Date: Monday, September 29, 2008, 8:43 AM

Hi Paul,

Thanks for the link, it makes the whole thing clearer. However, is that point 
still debatable? I quite disagree about the conclusion about forcing the 
upgrade of the core if you upgrade Tomahawk. Upgrading Tomahawk might force the 
upgrade of shared, but not necessarily if the former doesn't depend on a latest 
change to shared. Furthermore you don't need to upgrade core if you upgrade 
shared if the latter enforce backward compatibility.


Personally I must admit that I don't really like the preprocessing since it 
means having two of the same class on the classpath but in different packages 
if you use both core and Tomahawk.


Regards,


~ Simon

On Mon, Sep 29, 2008 at 12:10 AM, Paul Rivera <[EMAIL PROTECTED]> wrote:


Hi Simon,

I think this link explains it best:
http://wiki.apache.org/myfaces/Source_Code_Packaging

Best Regards,
Paul Rivera


--- On Sun, 9/28/08, Simon Lessard <[EMAIL PROTECTED]> wrote:

From: Simon Lessard <[EMAIL PROTECTED]>
Subject: MyFaces shared question
To: "MyFaces-Devs" 

Date: Sunday, September 28, 2008, 7:38 AM

Hi all,

Anyone knows why myfaces-shared is unpacked with a plugin by Maven instead of 
being a standard dependency?



Thanks,

~ Simon




  




  

[OT] Travel Assistance to ApacheCon US 2008 - 3 days to apply!

[Manfred Geiler]

The Travel Assistance Committee is taking in applications for those wanting
to attend ApacheCon US 2008 between the 3rd and 7th November 2008 in New
Orleans.

The Travel Assistance Committee is looking for people who would like to be
able to attend ApacheCon US 2008 who need some financial support in order to
get there. There are VERY few places available and the criteria is high,
that aside applications are open to all open source developers who feel that
their attendance would benefit themselves, their project(s), the ASF and
open source in general.

Financial assistance is available for flights, accommodation and entrance
fees either in full or in part, depending on circumstances. It is intended
that all our ApacheCon events are covered, so it may be prudent for those in
Europe and or Asia to wait until an event closer to them comes up - you are
all welcome to apply for ApacheCon US of course, but there must be
compelling reasons for you to attend an event further away that your home
location for your application to be considered above those closer to the
event location.

More information can be found on the main Apache website at
http://www.apache.org/travel/index.html - where you will also find a link to
the application form and details for submitting.

Time is very tight for this event, so applications are open now and will end
on the 2nd October 2008 - to give enough time for travel arrangements to be
made.

Good luck to all those that will apply.

Regards,

The Travel Assistance Committee

[jira] Updated: (TOBAGO-696) Popup elements look disabled with theme Scarborough and IE 6

[Helmut Swaczinna (JIRA)]

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

Helmut Swaczinna updated TOBAGO-696:


Status: Patch Available  (was: Open)

> Popup elements look disabled with theme Scarborough and IE 6
> 
>
> Key: TOBAGO-696
> URL: https://issues.apache.org/jira/browse/TOBAGO-696
> Project: MyFaces Tobago
>  Issue Type: Bug
>  Components: Themes
>Affects Versions: 1.0.18
> Environment: IE 6, online demo
>Reporter: Helmut Swaczinna
>
> You can see this in the online demo

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

[ANNOUNCE] JSFCentral Articles: Spring-Faces and NetAdvantage for JSF

[Kito Mann]

Hello,

I'm pleased to announce a couple of recent JSFCentral articles from JSFOne
speakers.
 
We just posted the first in a series of articles from Jeremy Grelle about
Spring Faces, the integration layer in-between Spring and JSF. Here's an
excerpt:

Spring Faces takes a much more prescriptive approach to integration between
JSF and Spring. A further strength of JSF is the many extension points it
provides, and Spring Faces takes full advantage of this to fit JSF more
naturally into a Spring world. It makes a number of assumptions about the
environment it is running in, such as a Spring MVC DispatcherServlet being
configured to handle request routing, and Spring Web Flow 2.x being
available as the primary controller model. It also builds upon the new
Spring JavaScript module to provide a number of lightweight JSF Ajax
components that focus on web development best practices, such as progressive
enhancement, graceful degradation, and accessibility. (Spring Faces is
designed to work with any JSF component library, thus the use of these
components is entirely optional.)

Read the rest of the article here:
http://www.jsfcentral.com/articles/intro_spring_faces_1.html. 

Stay tuned for future articles in this series!

Earlier, we also posted a podcast interview (with full transcript) featuring
Jim Cook, Product Manager for the NetAdvantage for JSF component suite. In
his first podcast interview, James Cook provides an excellent overview of
the NetAdvantage for JSF component suite. Here's an excerpt:

Kito:
Okay, so at Infragistics you are the Java product manager. Tell us about
Infragistics itself. 

James:
Infragistics is a company that is exclusively dedicated to building
front-end components for all varieties of platforms. We have Windows
offerings as well as our Java JSF offering. The company is about 20 years
old and the name Infragistics comes from a merger between Sheridan and
Protoview back in 2002 -- companies that had been building components. We
have a lot of length and depth of expertise in the component world. 

Kito:
Okay cool. Your product, as far as JSF is concerned, is called NetAdvantage
for JSF, right? So tell me about that.

James:
NetAdvantage for JSF is a set of JSF components that cover most of the
bases, or really all of the bases in the componentry world. Our tools are
Ajax enabled, they are fully JSF compliant and we have a very interactive
user grid, very interactive 2D and 3D charts, various input components as
you would expect, some layout components, a noodle tree, and with our new
release we have dialogue boxes that are based on CSS so they can't be
blocked by browser pop-up blockers or that sort of thing. They are very
configurable -- you can build entire wizards with them inside a browser. It
is all focused on making the browser look more like a standard GUI
application, which is really our goal for the JSF product. I should also
mention, with our new release we are also supporting Ajax inside a portal
environment, so if you are running IBM's WebSphere portal or JBoss' or
WebLogic's, you can now do portlet-to-portlet communication on the same page
using Ajax instead of doing wiring or any of the things you might do on the
administration side of the portal. That is something a lot of our customers
have been asking for.

Download the podcast or read the transcript here:
http://www.jsfcentral.com/articles/cook-08-08.html. 

You can expect more podcasts from JSFOne speakers throughout the year.
Enjoy!

NOTE: Please do not respond directly to this e-mail; it's cross-posted.

~~~
Kito D. Mann -- Author, JavaServer Faces in Action
http://twitter.com/kito99
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info

* Sign up for the JSF Central newsletter!
http://oi.vresp.com/?fid=ac048d0e17 *

[jira] Commented: (TOMAHAWK-1305) No error when file is uploaded larger than uploadMaxFileSize

[Gertjan van Oosten (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOMAHAWK-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635713#action_12635713
 ] 

Gertjan van Oosten commented on TOMAHAWK-1305:
--

Hmm, tricky...  Good analysis though! ;-)

A quick check in my environment shows that you can't rely on any order of the 
post parameters in the multipart/form-data request; in my first (and only) 
testcase the MIME parts were in this order:
- an input parameter
- the file data
- the save button of the form
- a parameter named myForm_SUBMIT with value 1
- a parameter named myForm:_icdl with empty value
- the parameter javax.faces.ViewState

If the ViewState comes after the file part and the request is aborted during 
the upload when that part is too large, you will certainly not be able to know 
the value of ViewState parameter.
I have currently no idea how to solve this in a user friendly way.  E.g. 
processing the entire upload even though it is way too large and only throwing 
the error after the complete upload has finished forces the user to wait longer 
than necessary.


> No error when file is uploaded larger than uploadMaxFileSize
> 
>
> Key: TOMAHAWK-1305
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1305
> Project: MyFaces Tomahawk
>  Issue Type: Bug
>  Components: File Upload
>Affects Versions: 1.1.7-SNAPSHOT
>Reporter: Gertjan van Oosten
>
> When a file is uploaded that is larger than the uploadMaxFileSize, the upload 
> is ignored but no error is shown.
> Reproducible with the fileupload example:
>   http://www.irian.at/myfacesexamples/fileupload.jsf
> Be patient, you need a file larger than 100 MBytes.

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

[jira] Commented: (TOMAHAWK-1305) No error when file is uploaded larger than uploadMaxFileSize

[Paul Rivera (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOMAHAWK-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635703#action_12635703
 ] 

Paul Rivera commented on TOMAHAWK-1305:
---

This issue is similar to TOMAHAWK-6.

I was able to replicate this issue locally with tomahawk 1.1.8-SNAPSHOT.  No 
messages shown in h:message even though the size was greater than 
uploadMaxFileSize.

I did some investigation and found out that:
  - Once commons upload determines that the size of the file being uploaded is 
greater than uploadMaxFileSize, it throws a SizeLimitExceededException.  This 
prevents it from doing further processing to read the request parameters.  (see 
org.apache.commons.fileupload.FileUploadBase)
  - RestoreViewExecutor looks for a request parameter named 
javax.faces.ViewState.  Since the request parameters were not read as mentioned 
above, javax.faces.ViewState will be null when RestoreViewExecutor looks for 
it.  RestoreViewExecutor finds no view to restore so it will treat it as a new 
page.  It will call facesContext.renderResponse() to skip the other phases and 
proceed with the render response phase immediately.
  - The code that adds a FacesMessage when the size limit is exceeded is inside 
AbstractHtmlInputFileUpload.validateValue(FacesContext context, Object 
convertedValue).  This method only gets called during the validation phase, 
which is skipped as mentioned above.  This is why there is no message shown in 
h:message.

I'm still thinking of a good way to fix this.  Maybe you have some ideas?

> No error when file is uploaded larger than uploadMaxFileSize
> 
>
> Key: TOMAHAWK-1305
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1305
> Project: MyFaces Tomahawk
>  Issue Type: Bug
>  Components: File Upload
>Affects Versions: 1.1.7-SNAPSHOT
>Reporter: Gertjan van Oosten
>
> When a file is uploaded that is larger than the uploadMaxFileSize, the upload 
> is ignored but no error is shown.
> Reproducible with the fileupload example:
>   http://www.irian.at/myfacesexamples/fileupload.jsf
> Be patient, you need a file larger than 100 MBytes.

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

[jira] Resolved: (TOBAGO-701) By using a tx:selectBooleanCheckbox component that is readonly the command facet still works

[Bernd Bohmann (JIRA)]

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

Bernd Bohmann resolved TOBAGO-701.
--

Resolution: Fixed

> By using a tx:selectBooleanCheckbox component that is readonly the command 
> facet still works
> 
>
> Key: TOBAGO-701
> URL: https://issues.apache.org/jira/browse/TOBAGO-701
> Project: MyFaces Tobago
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.18
>Reporter: Marcel Menze
>Assignee: Bernd Bohmann
> Fix For: 1.0.19
>
>
> By using a tx:selectBooleanCheckbox component that is readonly the command 
> facet still works

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

[jira] Resolved: (TOBAGO-176) Possibility to render a drop-down in a TabGroup for selection of 'invisible' tabs (Eclipse-style)

[Bernd Bohmann (JIRA)]

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

Bernd Bohmann resolved TOBAGO-176.
--

Resolution: Fixed

merging to 1.1.x is still missing

> Possibility to render a drop-down in a TabGroup for selection of 'invisible' 
> tabs (Eclipse-style)
> -
>
> Key: TOBAGO-176
> URL: https://issues.apache.org/jira/browse/TOBAGO-176
> Project: MyFaces Tobago
>  Issue Type: New Feature
>  Components: Core, Themes
>Affects Versions: 1.0.8
> Environment: Any and all
>Reporter: Roland Asmann
>Assignee: Bernd Bohmann
>Priority: Minor
> Fix For: 1.0.19, 1.1.0
>
>
> It would be great to have the possibility to render a drop-down next to all 
> tabs in a TabGroup to use as an overview of currently invisible (but open) 
> tabs. Would be great if it could be realized as part of the component, eg 
> telling the TabGroup how many tabs it can show and any more that are opened 
> push some of the already open ones to the drop-down.
> If this can't be realized as one component, it should at least be possible to 
> reserve some space on the same 'line' as the tabs in the TabGroup to render a 
> drop-down (or a menu or something similar) so users can implement the above 
> functionality themselves.
> One hint from the mailing-list:
> I think this should be included in the TabGroupRenderer. -- Bernd Bohmann

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