Re: Re: Re: Re: Problems with a custom component when migrating from Glassfish(mojarra) to TomEE
Well I don't understand why they call it a MenuRenderer, as far as I can see it's a superclass for uiselectone uiselectmany... No equalent superclass is used for myfaces by the looks of things. So you might need to rewrite the whole thing from scratch and paying attention to making it portable. What you have there seems to be a hierarchy like but with checkboxes instead. How does it work exactly? You select parent and it auto selects child nodes? Anyway if it's a bunch of selectone in a hierarchy you should be able to do it with css and ui:repeat and ajax? Give me a proper specification please Cheers On 14 February 2014 08:52, Rene Perschon wrote: > Well the imports of com.sun.faces are offending, starting with > MenuRenderer from which our custom renderer extends.. > I've already tried to just swap the imports (for example for Apache > Tobago's MenuRenderer, but it's final). I barely know about com.sun.faces > and i've never used MyFaces before, so it's really hard for me to figure > out the equivalents here > > > > Gesendet: Freitag, 14. Februar 2014 um 08:49 Uhr > Von: "Karl Kildén" > An: "MyFaces Discussion" > Betreff: Re: Re: Re: Problems with a custom component when migrating from > Glassfish(mojarra) to TomEE > Rene, I at least can't see anything. > > Another thing to think about it what impl stuff you have actually worked > with? I mean mojarra should have about the same stuff as myfaces? > To make myself clear, what does the components and stuff you extend really > belong to? Shouldn't be impossible to find equivalents in myfaces... > > > On 14 February 2014 08:45, Rene Perschon wrote: > > > Yes, here it is. It's a two-stage component which displays a hierarchical > > (2 levels) selection choice. > > > > > > > > Gesendet: Donnerstag, 13. Februar 2014 um 16:57 Uhr > > Von: "Howard W. Smith, Jr." > > An: "MyFaces Discussion" > > Betreff: Re: Re: Problems with a custom component when migrating from > > Glassfish(mojarra) to TomEE > > do you have a screen capture or some type of demo of the Select > component? > > > > > > > > On Thu, Feb 13, 2014 at 8:39 AM, Rene Perschon > > wrote: > > > > > I don't think a TagHandler or a custom component can do what that code > > > does. It's used to display a Select in a very specific way. > > > > > > > > > > > > Gesendet: Donnerstag, 13. Februar 2014 um 14:29 Uhr > > > Von: "Karl Kildén" > > > An: "MyFaces Discussion" > > > Betreff: Re: Problems with a custom component when migrating from > > > Glassfish(mojarra) to TomEE > > > Have you considered a custom tagHandler / composite component instead? > > > > > > I took a quick look but I don't recognize much sorry. > > > > > > > > > On 13 February 2014 14:09, Howard W. Smith, Jr. < > smithh032...@gmail.com > > > >wrote: > > > > > > > I think Leonardo, Gerhard, or one of the other committers may provide > > her > > > > some good help, just to get another MyFaces user, especially when one > > is > > > > migrating from Mojarra to MyFaces. > > > > > > > > @Renee, +1 your goal/request. > > > > > > > > I migrated from Mojarra to MyFaces, first, and then 2 months later, I > > > > migrated from Glassfish to tomee (and JSF managed beans to CDI > managed > > > > beans at same time). Thomas, Romain, Mark Struberg, and others > provided > > > > great help and motivation. Apache tomee, MyFaces, tomcat user mail > > lists > > > > are definitely the place to be. > > > > > > > > But I didn't have code dependent on the Mojarra library like you do. > > > Still, > > > > it took me about a week to migrate from Mojarra to MyFaces. Thomas > and > > > > Leonardo motivated me to start the migration after reading about the > > > > performance comparison between Mojarra and MyFaces. Mark Struberg > blog, > > > why > > > > is OpenWebBeans so fast, motivated me to migrate to CDI and tomee. > :-) > > > > > > > > I love high performance, that's why I opted to use MyFaces, tomee, > > > > OpenWebBeans, and JUEL. > > > > > > > > Wishing you much success. > > > > On Feb 13, 2014 7:23 AM, "Thomas Andraschko" < > > > andraschko.tho...@gmail.com> > > > > wrote: > > > > > > >
Aw: Re: Re: Re: Problems with a custom component when migrating from Glassfish(mojarra) to TomEE
Well the imports of com.sun.faces are offending, starting with MenuRenderer from which our custom renderer extends.. I've already tried to just swap the imports (for example for Apache Tobago's MenuRenderer, but it's final). I barely know about com.sun.faces and i've never used MyFaces before, so it's really hard for me to figure out the equivalents here Gesendet: Freitag, 14. Februar 2014 um 08:49 Uhr Von: "Karl Kildén" An: "MyFaces Discussion" Betreff: Re: Re: Re: Problems with a custom component when migrating from Glassfish(mojarra) to TomEE Rene, I at least can't see anything. Another thing to think about it what impl stuff you have actually worked with? I mean mojarra should have about the same stuff as myfaces? To make myself clear, what does the components and stuff you extend really belong to? Shouldn't be impossible to find equivalents in myfaces... On 14 February 2014 08:45, Rene Perschon wrote: > Yes, here it is. It's a two-stage component which displays a hierarchical > (2 levels) selection choice. > > > > Gesendet: Donnerstag, 13. Februar 2014 um 16:57 Uhr > Von: "Howard W. Smith, Jr." > An: "MyFaces Discussion" > Betreff: Re: Re: Problems with a custom component when migrating from > Glassfish(mojarra) to TomEE > do you have a screen capture or some type of demo of the Select component? > > > > On Thu, Feb 13, 2014 at 8:39 AM, Rene Perschon > wrote: > > > I don't think a TagHandler or a custom component can do what that code > > does. It's used to display a Select in a very specific way. > > > > > > > > Gesendet: Donnerstag, 13. Februar 2014 um 14:29 Uhr > > Von: "Karl Kildén" > > An: "MyFaces Discussion" > > Betreff: Re: Problems with a custom component when migrating from > > Glassfish(mojarra) to TomEE > > Have you considered a custom tagHandler / composite component instead? > > > > I took a quick look but I don't recognize much sorry. > > > > > > On 13 February 2014 14:09, Howard W. Smith, Jr. > >wrote: > > > > > I think Leonardo, Gerhard, or one of the other committers may provide > her > > > some good help, just to get another MyFaces user, especially when one > is > > > migrating from Mojarra to MyFaces. > > > > > > @Renee, +1 your goal/request. > > > > > > I migrated from Mojarra to MyFaces, first, and then 2 months later, I > > > migrated from Glassfish to tomee (and JSF managed beans to CDI managed > > > beans at same time). Thomas, Romain, Mark Struberg, and others provided > > > great help and motivation. Apache tomee, MyFaces, tomcat user mail > lists > > > are definitely the place to be. > > > > > > But I didn't have code dependent on the Mojarra library like you do. > > Still, > > > it took me about a week to migrate from Mojarra to MyFaces. Thomas and > > > Leonardo motivated me to start the migration after reading about the > > > performance comparison between Mojarra and MyFaces. Mark Struberg blog, > > why > > > is OpenWebBeans so fast, motivated me to migrate to CDI and tomee. :-) > > > > > > I love high performance, that's why I opted to use MyFaces, tomee, > > > OpenWebBeans, and JUEL. > > > > > > Wishing you much success. > > > On Feb 13, 2014 7:23 AM, "Thomas Andraschko" < > > andraschko.tho...@gmail.com> > > > wrote: > > > > > > > I don't think that anyone will port your complete code and give you a > > > > complete solution ;) > > > > > > > > The biggest problem is AFAIR that the renderer implementations are > not > > in > > > > the API packages. So you have to rebuild all this functionality > without > > > > dependencies to the Impl. > > > > > > > > e.g. > > > > Attribute,AttributeManager -> String[] with attribute namens > > > > Move all the utils functions to your own code > > (Util.componentIsDisabled, > > > > RenderKitUtils.getSelectItems. etc.) > > > > > > > > The most code doesn't really depent on the IMPL code. > > > > > > > > > > > > 2014-02-13 12:44 GMT+01:00 Rene Perschon : > > > > > > > > > Hi everyone! > > > > > > > > > > I'm currently migrating an application from Glassfish 3.1.1 to > TomEE. > > > Now > > > > > the problem is that this application contains a custom component >
Aw: Re: Re: Problems with a custom component when migrating from Glassfish(mojarra) to TomEE
of course, no attachments https://dl.dropboxusercontent.com/u/16379590/screens/custom_1.png https://dl.dropboxusercontent.com/u/16379590/screens/custom_2.png Gesendet: Donnerstag, 13. Februar 2014 um 16:57 Uhr Von: "Howard W. Smith, Jr." An: "MyFaces Discussion" Betreff: Re: Re: Problems with a custom component when migrating from Glassfish(mojarra) to TomEE do you have a screen capture or some type of demo of the Select component? On Thu, Feb 13, 2014 at 8:39 AM, Rene Perschon wrote: > I don't think a TagHandler or a custom component can do what that code > does. It's used to display a Select in a very specific way. > > > > Gesendet: Donnerstag, 13. Februar 2014 um 14:29 Uhr > Von: "Karl Kildén" > An: "MyFaces Discussion" > Betreff: Re: Problems with a custom component when migrating from > Glassfish(mojarra) to TomEE > Have you considered a custom tagHandler / composite component instead? > > I took a quick look but I don't recognize much sorry. > > > On 13 February 2014 14:09, Howard W. Smith, Jr. >wrote: > > > I think Leonardo, Gerhard, or one of the other committers may provide her > > some good help, just to get another MyFaces user, especially when one is > > migrating from Mojarra to MyFaces. > > > > @Renee, +1 your goal/request. > > > > I migrated from Mojarra to MyFaces, first, and then 2 months later, I > > migrated from Glassfish to tomee (and JSF managed beans to CDI managed > > beans at same time). Thomas, Romain, Mark Struberg, and others provided > > great help and motivation. Apache tomee, MyFaces, tomcat user mail lists > > are definitely the place to be. > > > > But I didn't have code dependent on the Mojarra library like you do. > Still, > > it took me about a week to migrate from Mojarra to MyFaces. Thomas and > > Leonardo motivated me to start the migration after reading about the > > performance comparison between Mojarra and MyFaces. Mark Struberg blog, > why > > is OpenWebBeans so fast, motivated me to migrate to CDI and tomee. :-) > > > > I love high performance, that's why I opted to use MyFaces, tomee, > > OpenWebBeans, and JUEL. > > > > Wishing you much success. > > On Feb 13, 2014 7:23 AM, "Thomas Andraschko" < > andraschko.tho...@gmail.com> > > wrote: > > > > > I don't think that anyone will port your complete code and give you a > > > complete solution ;) > > > > > > The biggest problem is AFAIR that the renderer implementations are not > in > > > the API packages. So you have to rebuild all this functionality without > > > dependencies to the Impl. > > > > > > e.g. > > > Attribute,AttributeManager -> String[] with attribute namens > > > Move all the utils functions to your own code > (Util.componentIsDisabled, > > > RenderKitUtils.getSelectItems. etc.) > > > > > > The most code doesn't really depent on the IMPL code. > > > > > > > > > 2014-02-13 12:44 GMT+01:00 Rene Perschon : > > > > > > > Hi everyone! > > > > > > > > I'm currently migrating an application from Glassfish 3.1.1 to TomEE. > > Now > > > > the problem is that this application contains a custom component > which > > > was > > > > unfortunately coded with hard dependencies on com.sun.faces classes > > > (maven > > > > dependency jsf-impl). > > > > > > > > Now my question is how can i port this component in such a way that > it > > is > > > > independent from any concrete JSF implementation (or at least in > such a > > > way > > > > that it works with MyFaces). > > > > > > > > Here's the component: > > > > > > > > import java.io.IOException; > > > > import java.util.Iterator; > > > > import java.util.Map; > > > > > > > > import javax.faces.component.UIComponent; > > > > import javax.faces.component.UINamingContainer; > > > > import javax.faces.component.ValueHolder; > > > > import javax.faces.context.FacesContext; > > > > import javax.faces.context.ResponseWriter; > > > > import javax.faces.convert.Converter; > > > > import javax.faces.model.SelectItem; > > > > import javax.faces.model.SelectItemGroup; > > > > > > > > import com.sun.faces.renderkit.Attribute; > > > > import com.sun.faces.renderkit.AttributeManager; > > > > import com.su
Re: Re: Re: Problems with a custom component when migrating from Glassfish(mojarra) to TomEE
Rene, I at least can't see anything. Another thing to think about it what impl stuff you have actually worked with? I mean mojarra should have about the same stuff as myfaces? To make myself clear, what does the components and stuff you extend really belong to? Shouldn't be impossible to find equivalents in myfaces... On 14 February 2014 08:45, Rene Perschon wrote: > Yes, here it is. It's a two-stage component which displays a hierarchical > (2 levels) selection choice. > > > > Gesendet: Donnerstag, 13. Februar 2014 um 16:57 Uhr > Von: "Howard W. Smith, Jr." > An: "MyFaces Discussion" > Betreff: Re: Re: Problems with a custom component when migrating from > Glassfish(mojarra) to TomEE > do you have a screen capture or some type of demo of the Select component? > > > > On Thu, Feb 13, 2014 at 8:39 AM, Rene Perschon > wrote: > > > I don't think a TagHandler or a custom component can do what that code > > does. It's used to display a Select in a very specific way. > > > > > > > > Gesendet: Donnerstag, 13. Februar 2014 um 14:29 Uhr > > Von: "Karl Kildén" > > An: "MyFaces Discussion" > > Betreff: Re: Problems with a custom component when migrating from > > Glassfish(mojarra) to TomEE > > Have you considered a custom tagHandler / composite component instead? > > > > I took a quick look but I don't recognize much sorry. > > > > > > On 13 February 2014 14:09, Howard W. Smith, Jr. > >wrote: > > > > > I think Leonardo, Gerhard, or one of the other committers may provide > her > > > some good help, just to get another MyFaces user, especially when one > is > > > migrating from Mojarra to MyFaces. > > > > > > @Renee, +1 your goal/request. > > > > > > I migrated from Mojarra to MyFaces, first, and then 2 months later, I > > > migrated from Glassfish to tomee (and JSF managed beans to CDI managed > > > beans at same time). Thomas, Romain, Mark Struberg, and others provided > > > great help and motivation. Apache tomee, MyFaces, tomcat user mail > lists > > > are definitely the place to be. > > > > > > But I didn't have code dependent on the Mojarra library like you do. > > Still, > > > it took me about a week to migrate from Mojarra to MyFaces. Thomas and > > > Leonardo motivated me to start the migration after reading about the > > > performance comparison between Mojarra and MyFaces. Mark Struberg blog, > > why > > > is OpenWebBeans so fast, motivated me to migrate to CDI and tomee. :-) > > > > > > I love high performance, that's why I opted to use MyFaces, tomee, > > > OpenWebBeans, and JUEL. > > > > > > Wishing you much success. > > > On Feb 13, 2014 7:23 AM, "Thomas Andraschko" < > > andraschko.tho...@gmail.com> > > > wrote: > > > > > > > I don't think that anyone will port your complete code and give you a > > > > complete solution ;) > > > > > > > > The biggest problem is AFAIR that the renderer implementations are > not > > in > > > > the API packages. So you have to rebuild all this functionality > without > > > > dependencies to the Impl. > > > > > > > > e.g. > > > > Attribute,AttributeManager -> String[] with attribute namens > > > > Move all the utils functions to your own code > > (Util.componentIsDisabled, > > > > RenderKitUtils.getSelectItems. etc.) > > > > > > > > The most code doesn't really depent on the IMPL code. > > > > > > > > > > > > 2014-02-13 12:44 GMT+01:00 Rene Perschon : > > > > > > > > > Hi everyone! > > > > > > > > > > I'm currently migrating an application from Glassfish 3.1.1 to > TomEE. > > > Now > > > > > the problem is that this application contains a custom component > > which > > > > was > > > > > unfortunately coded with hard dependencies on com.sun.faces classes > > > > (maven > > > > > dependency jsf-impl). > > > > > > > > > > Now my question is how can i port this component in such a way that > > it > > > is > > > > > independent from any concrete JSF implementation (or at least in > > such a > > > > way > > > > > that it works with MyFaces). > > > > > > > >
Aw: Re: Re: Problems with a custom component when migrating from Glassfish(mojarra) to TomEE
Yes, here it is. It's a two-stage component which displays a hierarchical (2 levels) selection choice. Gesendet: Donnerstag, 13. Februar 2014 um 16:57 Uhr Von: "Howard W. Smith, Jr." An: "MyFaces Discussion" Betreff: Re: Re: Problems with a custom component when migrating from Glassfish(mojarra) to TomEE do you have a screen capture or some type of demo of the Select component? On Thu, Feb 13, 2014 at 8:39 AM, Rene Perschon wrote: > I don't think a TagHandler or a custom component can do what that code > does. It's used to display a Select in a very specific way. > > > > Gesendet: Donnerstag, 13. Februar 2014 um 14:29 Uhr > Von: "Karl Kildén" > An: "MyFaces Discussion" > Betreff: Re: Problems with a custom component when migrating from > Glassfish(mojarra) to TomEE > Have you considered a custom tagHandler / composite component instead? > > I took a quick look but I don't recognize much sorry. > > > On 13 February 2014 14:09, Howard W. Smith, Jr. >wrote: > > > I think Leonardo, Gerhard, or one of the other committers may provide her > > some good help, just to get another MyFaces user, especially when one is > > migrating from Mojarra to MyFaces. > > > > @Renee, +1 your goal/request. > > > > I migrated from Mojarra to MyFaces, first, and then 2 months later, I > > migrated from Glassfish to tomee (and JSF managed beans to CDI managed > > beans at same time). Thomas, Romain, Mark Struberg, and others provided > > great help and motivation. Apache tomee, MyFaces, tomcat user mail lists > > are definitely the place to be. > > > > But I didn't have code dependent on the Mojarra library like you do. > Still, > > it took me about a week to migrate from Mojarra to MyFaces. Thomas and > > Leonardo motivated me to start the migration after reading about the > > performance comparison between Mojarra and MyFaces. Mark Struberg blog, > why > > is OpenWebBeans so fast, motivated me to migrate to CDI and tomee. :-) > > > > I love high performance, that's why I opted to use MyFaces, tomee, > > OpenWebBeans, and JUEL. > > > > Wishing you much success. > > On Feb 13, 2014 7:23 AM, "Thomas Andraschko" < > andraschko.tho...@gmail.com> > > wrote: > > > > > I don't think that anyone will port your complete code and give you a > > > complete solution ;) > > > > > > The biggest problem is AFAIR that the renderer implementations are not > in > > > the API packages. So you have to rebuild all this functionality without > > > dependencies to the Impl. > > > > > > e.g. > > > Attribute,AttributeManager -> String[] with attribute namens > > > Move all the utils functions to your own code > (Util.componentIsDisabled, > > > RenderKitUtils.getSelectItems. etc.) > > > > > > The most code doesn't really depent on the IMPL code. > > > > > > > > > 2014-02-13 12:44 GMT+01:00 Rene Perschon : > > > > > > > Hi everyone! > > > > > > > > I'm currently migrating an application from Glassfish 3.1.1 to TomEE. > > Now > > > > the problem is that this application contains a custom component > which > > > was > > > > unfortunately coded with hard dependencies on com.sun.faces classes > > > (maven > > > > dependency jsf-impl). > > > > > > > > Now my question is how can i port this component in such a way that > it > > is > > > > independent from any concrete JSF implementation (or at least in > such a > > > way > > > > that it works with MyFaces). > > > > > > > > Here's the component: > > > > > > > > import java.io.IOException; > > > > import java.util.Iterator; > > > > import java.util.Map; > > > > > > > > import javax.faces.component.UIComponent; > > > > import javax.faces.component.UINamingContainer; > > > > import javax.faces.component.ValueHolder; > > > > import javax.faces.context.FacesContext; > > > > import javax.faces.context.ResponseWriter; > > > > import javax.faces.convert.Converter; > > > > import javax.faces.model.SelectItem; > > > > import javax.faces.model.SelectItemGroup; > > > > > > > > import com.sun.faces.renderkit.Attribute; > > > > import com.sun.faces.renderkit.AttributeManager; > > > > import com.sun.faces.renderkit.RenderKitUtils; > > >
Re: Re: Problems with a custom component when migrating from Glassfish(mojarra) to TomEE
do you have a screen capture or some type of demo of the Select component?
On Thu, Feb 13, 2014 at 8:39 AM, Rene Perschon wrote:
> I don't think a TagHandler or a custom component can do what that code
> does. It's used to display a Select in a very specific way.
>
>
>
> Gesendet: Donnerstag, 13. Februar 2014 um 14:29 Uhr
> Von: "Karl Kildén"
> An: "MyFaces Discussion"
> Betreff: Re: Problems with a custom component when migrating from
> Glassfish(mojarra) to TomEE
> Have you considered a custom tagHandler / composite component instead?
>
> I took a quick look but I don't recognize much sorry.
>
>
> On 13 February 2014 14:09, Howard W. Smith, Jr. >wrote:
>
> > I think Leonardo, Gerhard, or one of the other committers may provide her
> > some good help, just to get another MyFaces user, especially when one is
> > migrating from Mojarra to MyFaces.
> >
> > @Renee, +1 your goal/request.
> >
> > I migrated from Mojarra to MyFaces, first, and then 2 months later, I
> > migrated from Glassfish to tomee (and JSF managed beans to CDI managed
> > beans at same time). Thomas, Romain, Mark Struberg, and others provided
> > great help and motivation. Apache tomee, MyFaces, tomcat user mail lists
> > are definitely the place to be.
> >
> > But I didn't have code dependent on the Mojarra library like you do.
> Still,
> > it took me about a week to migrate from Mojarra to MyFaces. Thomas and
> > Leonardo motivated me to start the migration after reading about the
> > performance comparison between Mojarra and MyFaces. Mark Struberg blog,
> why
> > is OpenWebBeans so fast, motivated me to migrate to CDI and tomee. :-)
> >
> > I love high performance, that's why I opted to use MyFaces, tomee,
> > OpenWebBeans, and JUEL.
> >
> > Wishing you much success.
> > On Feb 13, 2014 7:23 AM, "Thomas Andraschko" <
> andraschko.tho...@gmail.com>
> > wrote:
> >
> > > I don't think that anyone will port your complete code and give you a
> > > complete solution ;)
> > >
> > > The biggest problem is AFAIR that the renderer implementations are not
> in
> > > the API packages. So you have to rebuild all this functionality without
> > > dependencies to the Impl.
> > >
> > > e.g.
> > > Attribute,AttributeManager -> String[] with attribute namens
> > > Move all the utils functions to your own code
> (Util.componentIsDisabled,
> > > RenderKitUtils.getSelectItems. etc.)
> > >
> > > The most code doesn't really depent on the IMPL code.
> > >
> > >
> > > 2014-02-13 12:44 GMT+01:00 Rene Perschon :
> > >
> > > > Hi everyone!
> > > >
> > > > I'm currently migrating an application from Glassfish 3.1.1 to TomEE.
> > Now
> > > > the problem is that this application contains a custom component
> which
> > > was
> > > > unfortunately coded with hard dependencies on com.sun.faces classes
> > > (maven
> > > > dependency jsf-impl).
> > > >
> > > > Now my question is how can i port this component in such a way that
> it
> > is
> > > > independent from any concrete JSF implementation (or at least in
> such a
> > > way
> > > > that it works with MyFaces).
> > > >
> > > > Here's the component:
> > > >
> > > > import java.io.IOException;
> > > > import java.util.Iterator;
> > > > import java.util.Map;
> > > >
> > > > import javax.faces.component.UIComponent;
> > > > import javax.faces.component.UINamingContainer;
> > > > import javax.faces.component.ValueHolder;
> > > > import javax.faces.context.FacesContext;
> > > > import javax.faces.context.ResponseWriter;
> > > > import javax.faces.convert.Converter;
> > > > import javax.faces.model.SelectItem;
> > > > import javax.faces.model.SelectItemGroup;
> > > >
> > > > import com.sun.faces.renderkit.Attribute;
> > > > import com.sun.faces.renderkit.AttributeManager;
> > > > import com.sun.faces.renderkit.RenderKitUtils;
> > > > import com.sun.faces.renderkit.html_basic.MenuRenderer;
> > > > import com.sun.faces.util.RequestStateManager;
> > > > import com.sun.faces.util.Util;
> > > >
> > > > /**
> > > > * {@inheritDoc}.
> > > > */
> > > > public class CustomSelectManyCheckbox
Aw: Re: Problems with a custom component when migrating from Glassfish(mojarra) to TomEE
I don't think a TagHandler or a custom component can do what that code does.
It's used to display a Select in a very specific way.
Gesendet: Donnerstag, 13. Februar 2014 um 14:29 Uhr
Von: "Karl Kildén"
An: "MyFaces Discussion"
Betreff: Re: Problems with a custom component when migrating from
Glassfish(mojarra) to TomEE
Have you considered a custom tagHandler / composite component instead?
I took a quick look but I don't recognize much sorry.
On 13 February 2014 14:09, Howard W. Smith, Jr. wrote:
> I think Leonardo, Gerhard, or one of the other committers may provide her
> some good help, just to get another MyFaces user, especially when one is
> migrating from Mojarra to MyFaces.
>
> @Renee, +1 your goal/request.
>
> I migrated from Mojarra to MyFaces, first, and then 2 months later, I
> migrated from Glassfish to tomee (and JSF managed beans to CDI managed
> beans at same time). Thomas, Romain, Mark Struberg, and others provided
> great help and motivation. Apache tomee, MyFaces, tomcat user mail lists
> are definitely the place to be.
>
> But I didn't have code dependent on the Mojarra library like you do. Still,
> it took me about a week to migrate from Mojarra to MyFaces. Thomas and
> Leonardo motivated me to start the migration after reading about the
> performance comparison between Mojarra and MyFaces. Mark Struberg blog, why
> is OpenWebBeans so fast, motivated me to migrate to CDI and tomee. :-)
>
> I love high performance, that's why I opted to use MyFaces, tomee,
> OpenWebBeans, and JUEL.
>
> Wishing you much success.
> On Feb 13, 2014 7:23 AM, "Thomas Andraschko"
> wrote:
>
> > I don't think that anyone will port your complete code and give you a
> > complete solution ;)
> >
> > The biggest problem is AFAIR that the renderer implementations are not in
> > the API packages. So you have to rebuild all this functionality without
> > dependencies to the Impl.
> >
> > e.g.
> > Attribute,AttributeManager -> String[] with attribute namens
> > Move all the utils functions to your own code (Util.componentIsDisabled,
> > RenderKitUtils.getSelectItems. etc.)
> >
> > The most code doesn't really depent on the IMPL code.
> >
> >
> > 2014-02-13 12:44 GMT+01:00 Rene Perschon :
> >
> > > Hi everyone!
> > >
> > > I'm currently migrating an application from Glassfish 3.1.1 to TomEE.
> Now
> > > the problem is that this application contains a custom component which
> > was
> > > unfortunately coded with hard dependencies on com.sun.faces classes
> > (maven
> > > dependency jsf-impl).
> > >
> > > Now my question is how can i port this component in such a way that it
> is
> > > independent from any concrete JSF implementation (or at least in such a
> > way
> > > that it works with MyFaces).
> > >
> > > Here's the component:
> > >
> > > import java.io.IOException;
> > > import java.util.Iterator;
> > > import java.util.Map;
> > >
> > > import javax.faces.component.UIComponent;
> > > import javax.faces.component.UINamingContainer;
> > > import javax.faces.component.ValueHolder;
> > > import javax.faces.context.FacesContext;
> > > import javax.faces.context.ResponseWriter;
> > > import javax.faces.convert.Converter;
> > > import javax.faces.model.SelectItem;
> > > import javax.faces.model.SelectItemGroup;
> > >
> > > import com.sun.faces.renderkit.Attribute;
> > > import com.sun.faces.renderkit.AttributeManager;
> > > import com.sun.faces.renderkit.RenderKitUtils;
> > > import com.sun.faces.renderkit.html_basic.MenuRenderer;
> > > import com.sun.faces.util.RequestStateManager;
> > > import com.sun.faces.util.Util;
> > >
> > > /**
> > > * {@inheritDoc}.
> > > */
> > > public class CustomSelectManyCheckboxListRenderer extends MenuRenderer
> > > {
> > > /** {@inheritDoc}. */
> > > private static final Attribute[] ATTRIBUTES =
> > >
> AttributeManager.getAttributes(AttributeManager.Key.SELECTMANYCHECKBOX);
> > > /** Representing the border string. */
> > > private static final String BORDER = "border";
> > > /** Representing the tr string. */
> > > private static final String TR = "tr";
> > > /** Representing the td string. */
> > > private static final String TD = "td";
> > > /** Representing the label string. */
> > > private static final String LABEL = "
Re: Problems with a custom component when migrating from Glassfish(mojarra) to TomEE
Have you considered a custom tagHandler / composite component instead?
I took a quick look but I don't recognize much sorry.
On 13 February 2014 14:09, Howard W. Smith, Jr. wrote:
> I think Leonardo, Gerhard, or one of the other committers may provide her
> some good help, just to get another MyFaces user, especially when one is
> migrating from Mojarra to MyFaces.
>
> @Renee, +1 your goal/request.
>
> I migrated from Mojarra to MyFaces, first, and then 2 months later, I
> migrated from Glassfish to tomee (and JSF managed beans to CDI managed
> beans at same time). Thomas, Romain, Mark Struberg, and others provided
> great help and motivation. Apache tomee, MyFaces, tomcat user mail lists
> are definitely the place to be.
>
> But I didn't have code dependent on the Mojarra library like you do. Still,
> it took me about a week to migrate from Mojarra to MyFaces. Thomas and
> Leonardo motivated me to start the migration after reading about the
> performance comparison between Mojarra and MyFaces. Mark Struberg blog, why
> is OpenWebBeans so fast, motivated me to migrate to CDI and tomee. :-)
>
> I love high performance, that's why I opted to use MyFaces, tomee,
> OpenWebBeans, and JUEL.
>
> Wishing you much success.
> On Feb 13, 2014 7:23 AM, "Thomas Andraschko"
> wrote:
>
> > I don't think that anyone will port your complete code and give you a
> > complete solution ;)
> >
> > The biggest problem is AFAIR that the renderer implementations are not in
> > the API packages. So you have to rebuild all this functionality without
> > dependencies to the Impl.
> >
> > e.g.
> > Attribute,AttributeManager -> String[] with attribute namens
> > Move all the utils functions to your own code (Util.componentIsDisabled,
> > RenderKitUtils.getSelectItems. etc.)
> >
> > The most code doesn't really depent on the IMPL code.
> >
> >
> > 2014-02-13 12:44 GMT+01:00 Rene Perschon :
> >
> > > Hi everyone!
> > >
> > > I'm currently migrating an application from Glassfish 3.1.1 to TomEE.
> Now
> > > the problem is that this application contains a custom component which
> > was
> > > unfortunately coded with hard dependencies on com.sun.faces classes
> > (maven
> > > dependency jsf-impl).
> > >
> > > Now my question is how can i port this component in such a way that it
> is
> > > independent from any concrete JSF implementation (or at least in such a
> > way
> > > that it works with MyFaces).
> > >
> > > Here's the component:
> > >
> > > import java.io.IOException;
> > > import java.util.Iterator;
> > > import java.util.Map;
> > >
> > > import javax.faces.component.UIComponent;
> > > import javax.faces.component.UINamingContainer;
> > > import javax.faces.component.ValueHolder;
> > > import javax.faces.context.FacesContext;
> > > import javax.faces.context.ResponseWriter;
> > > import javax.faces.convert.Converter;
> > > import javax.faces.model.SelectItem;
> > > import javax.faces.model.SelectItemGroup;
> > >
> > > import com.sun.faces.renderkit.Attribute;
> > > import com.sun.faces.renderkit.AttributeManager;
> > > import com.sun.faces.renderkit.RenderKitUtils;
> > > import com.sun.faces.renderkit.html_basic.MenuRenderer;
> > > import com.sun.faces.util.RequestStateManager;
> > > import com.sun.faces.util.Util;
> > >
> > > /**
> > > * {@inheritDoc}.
> > > */
> > > public class CustomSelectManyCheckboxListRenderer extends MenuRenderer
> > > {
> > > /** {@inheritDoc}. */
> > > private static final Attribute[] ATTRIBUTES =
> > >
> AttributeManager.getAttributes(AttributeManager.Key.SELECTMANYCHECKBOX);
> > > /** Representing the border string. */
> > > private static final String BORDER = "border";
> > > /** Representing the tr string. */
> > > private static final String TR = "tr";
> > > /** Representing the td string. */
> > > private static final String TD = "td";
> > > /** Representing the label string. */
> > > private static final String LABEL = "label";
> > > /** Representing the newline string. */
> > > private static final String NEWLINE = "\n";
> > > /** Representing the tab string. */
> > > private static final String TAB = "\t";
> > > /** Representing the class string. */
> > > private static final String CLASS = "class";
> > > /** Representing the style string. */
> > > private static final String STYLE = "style";
> > > /** Representing the valign string. */
> > > private static final String VALIGN = "valign";
> > >
> > >
> > > // --
> Public
> > > Methods
> > >
> > >
> > > @Override
> > > public void encodeEnd(FacesContext context, UIComponent component)
> > > throws IOException
> > > {
> > >
> > > rendererParamsNotNull(context, component);
> > >
> > > if (!shouldEncode(component))
> > > {
> > > return;
> > > }
> > >
> > > ResponseWriter writer = context.getResponseWriter();
> > > assert (writer != null)
Re: Problems with a custom component when migrating from Glassfish(mojarra) to TomEE
I think Leonardo, Gerhard, or one of the other committers may provide her
some good help, just to get another MyFaces user, especially when one is
migrating from Mojarra to MyFaces.
@Renee, +1 your goal/request.
I migrated from Mojarra to MyFaces, first, and then 2 months later, I
migrated from Glassfish to tomee (and JSF managed beans to CDI managed
beans at same time). Thomas, Romain, Mark Struberg, and others provided
great help and motivation. Apache tomee, MyFaces, tomcat user mail lists
are definitely the place to be.
But I didn't have code dependent on the Mojarra library like you do. Still,
it took me about a week to migrate from Mojarra to MyFaces. Thomas and
Leonardo motivated me to start the migration after reading about the
performance comparison between Mojarra and MyFaces. Mark Struberg blog, why
is OpenWebBeans so fast, motivated me to migrate to CDI and tomee. :-)
I love high performance, that's why I opted to use MyFaces, tomee,
OpenWebBeans, and JUEL.
Wishing you much success.
On Feb 13, 2014 7:23 AM, "Thomas Andraschko"
wrote:
> I don't think that anyone will port your complete code and give you a
> complete solution ;)
>
> The biggest problem is AFAIR that the renderer implementations are not in
> the API packages. So you have to rebuild all this functionality without
> dependencies to the Impl.
>
> e.g.
> Attribute,AttributeManager -> String[] with attribute namens
> Move all the utils functions to your own code (Util.componentIsDisabled,
> RenderKitUtils.getSelectItems. etc.)
>
> The most code doesn't really depent on the IMPL code.
>
>
> 2014-02-13 12:44 GMT+01:00 Rene Perschon :
>
> > Hi everyone!
> >
> > I'm currently migrating an application from Glassfish 3.1.1 to TomEE. Now
> > the problem is that this application contains a custom component which
> was
> > unfortunately coded with hard dependencies on com.sun.faces classes
> (maven
> > dependency jsf-impl).
> >
> > Now my question is how can i port this component in such a way that it is
> > independent from any concrete JSF implementation (or at least in such a
> way
> > that it works with MyFaces).
> >
> > Here's the component:
> >
> > import java.io.IOException;
> > import java.util.Iterator;
> > import java.util.Map;
> >
> > import javax.faces.component.UIComponent;
> > import javax.faces.component.UINamingContainer;
> > import javax.faces.component.ValueHolder;
> > import javax.faces.context.FacesContext;
> > import javax.faces.context.ResponseWriter;
> > import javax.faces.convert.Converter;
> > import javax.faces.model.SelectItem;
> > import javax.faces.model.SelectItemGroup;
> >
> > import com.sun.faces.renderkit.Attribute;
> > import com.sun.faces.renderkit.AttributeManager;
> > import com.sun.faces.renderkit.RenderKitUtils;
> > import com.sun.faces.renderkit.html_basic.MenuRenderer;
> > import com.sun.faces.util.RequestStateManager;
> > import com.sun.faces.util.Util;
> >
> > /**
> > * {@inheritDoc}.
> > */
> > public class CustomSelectManyCheckboxListRenderer extends MenuRenderer
> > {
> > /** {@inheritDoc}. */
> > private static final Attribute[] ATTRIBUTES =
> > AttributeManager.getAttributes(AttributeManager.Key.SELECTMANYCHECKBOX);
> > /** Representing the border string. */
> > private static final String BORDER = "border";
> > /** Representing the tr string. */
> > private static final String TR = "tr";
> > /** Representing the td string. */
> > private static final String TD = "td";
> > /** Representing the label string. */
> > private static final String LABEL = "label";
> > /** Representing the newline string. */
> > private static final String NEWLINE = "\n";
> > /** Representing the tab string. */
> > private static final String TAB = "\t";
> > /** Representing the class string. */
> > private static final String CLASS = "class";
> > /** Representing the style string. */
> > private static final String STYLE = "style";
> > /** Representing the valign string. */
> > private static final String VALIGN = "valign";
> >
> >
> > // -- Public
> > Methods
> >
> >
> > @Override
> > public void encodeEnd(FacesContext context, UIComponent component)
> > throws IOException
> > {
> >
> > rendererParamsNotNull(context, component);
> >
> > if (!shouldEncode(component))
> > {
> > return;
> > }
> >
> > ResponseWriter writer = context.getResponseWriter();
> > assert (writer != null);
> >
> > String alignStr;
> > Object borderObj;
> > boolean alignVertical = false;
> > int border = 0;
> >
> >
> >
> > if (null != component.getAttributes().get("layout"))
> > {
> > alignStr = (String) component.getAttributes().get("layout");
> > alignVertical = alignStr.equalsIgnoreCase("pageDirection");
> > }
> >
> > if (null != component.ge
Aw: Re: Problems with a custom component when migrating from Glassfish(mojarra) to TomEE
Agreed, i really don't want to deploy Mojarra to TomEE. Problem is I don't know
how to port the Mojarra dependent code to MyFaces. It starts with me not
knowing which MyFaces maven dependencies i need to import to "replace" the old
imports..
Gesendet: Donnerstag, 13. Februar 2014 um 13:25 Uhr
Von: "Romain Manni-Bucau"
An: "MyFaces Discussion"
Betreff: Re: Problems with a custom component when migrating from
Glassfish(mojarra) to TomEE
in tomee you can also use mojarra but I'd just keep my component
portable with myfaces if possible
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn:
http://fr.linkedin.com/in/rmannibucau[http://fr.linkedin.com/in/rmannibucau]
Github: https://github.com/rmannibucau[https://github.com/rmannibucau]
2014-02-13 13:23 GMT+01:00 Thomas Andraschko :
> I don't think that anyone will port your complete code and give you a
> complete solution ;)
>
> The biggest problem is AFAIR that the renderer implementations are not in
> the API packages. So you have to rebuild all this functionality without
> dependencies to the Impl.
>
> e.g.
> Attribute,AttributeManager -> String[] with attribute namens
> Move all the utils functions to your own code (Util.componentIsDisabled,
> RenderKitUtils.getSelectItems. etc.)
>
> The most code doesn't really depent on the IMPL code.
>
>
> 2014-02-13 12:44 GMT+01:00 Rene Perschon :
>
>> Hi everyone!
>>
>> I'm currently migrating an application from Glassfish 3.1.1 to TomEE. Now
>> the problem is that this application contains a custom component which was
>> unfortunately coded with hard dependencies on com.sun.faces classes (maven
>> dependency jsf-impl).
>>
>> Now my question is how can i port this component in such a way that it is
>> independent from any concrete JSF implementation (or at least in such a way
>> that it works with MyFaces).
>>
>> Here's the component:
>>
>> import java.io.IOException;
>> import java.util.Iterator;
>> import java.util.Map;
>>
>> import javax.faces.component.UIComponent;
>> import javax.faces.component.UINamingContainer;
>> import javax.faces.component.ValueHolder;
>> import javax.faces.context.FacesContext;
>> import javax.faces.context.ResponseWriter;
>> import javax.faces.convert.Converter;
>> import javax.faces.model.SelectItem;
>> import javax.faces.model.SelectItemGroup;
>>
>> import com.sun.faces.renderkit.Attribute;
>> import com.sun.faces.renderkit.AttributeManager;
>> import com.sun.faces.renderkit.RenderKitUtils;
>> import com.sun.faces.renderkit.html_basic.MenuRenderer;
>> import com.sun.faces.util.RequestStateManager;
>> import com.sun.faces.util.Util;
>>
>> /**
>> * {@inheritDoc}.
>> */
>> public class CustomSelectManyCheckboxListRenderer extends MenuRenderer
>> {
>> /** {@inheritDoc}. */
>> private static final Attribute[] ATTRIBUTES =
>> AttributeManager.getAttributes(AttributeManager.Key.SELECTMANYCHECKBOX);
>> /** Representing the border string. */
>> private static final String BORDER = "border";
>> /** Representing the tr string. */
>> private static final String TR = "tr";
>> /** Representing the td string. */
>> private static final String TD = "td";
>> /** Representing the label string. */
>> private static final String LABEL = "label";
>> /** Representing the newline string. */
>> private static final String NEWLINE = "\n";
>> /** Representing the tab string. */
>> private static final String TAB = "\t";
>> /** Representing the class string. */
>> private static final String CLASS = "class";
>> /** Representing the style string. */
>> private static final String STYLE = "style";
>> /** Representing the valign string. */
>> private static final String VALIGN = "valign";
>>
>>
>> // -- Public
>> Methods
>>
>>
>> @Override
>> public void encodeEnd(FacesContext context, UIComponent component)
>> throws IOException
>> {
>>
>> rendererParamsNotNull(context, component);
>>
>> if (!shouldEncode(component))
>> {
>> return;
>> }
>>
>> ResponseWriter writer = context.getResponseWriter();
>> assert (writer != null);
>>
>> String alignStr;
>> Object borderObj;
>> boolean alignVertical = false;
>> int border = 0;
>>
>>
>>
>> if (null != component.getAttributes().get("layou
Aw: Re: Problems with a custom component when migrating from Glassfish(mojarra) to TomEE
I didn't expect anyone to rewrite that code, i just wanted to present the whole
problem :-)
As i said, i'd accept a MyFaces port too, it's just that my shots at a solution
were unsuccessful. For example I tried to extend from Tobago's MenuRenderer
instead of Mojarra's, but it said that MenuRenderer in Tobago is final,
although I'm not sure that that's the correct approach in the first place.
Gesendet: Donnerstag, 13. Februar 2014 um 13:23 Uhr
Von: "Thomas Andraschko"
An: "MyFaces Discussion"
Betreff: Re: Problems with a custom component when migrating from
Glassfish(mojarra) to TomEE
I don't think that anyone will port your complete code and give you a
complete solution ;)
The biggest problem is AFAIR that the renderer implementations are not in
the API packages. So you have to rebuild all this functionality without
dependencies to the Impl.
e.g.
Attribute,AttributeManager -> String[] with attribute namens
Move all the utils functions to your own code (Util.componentIsDisabled,
RenderKitUtils.getSelectItems. etc.)
The most code doesn't really depent on the IMPL code.
2014-02-13 12:44 GMT+01:00 Rene Perschon :
> Hi everyone!
>
> I'm currently migrating an application from Glassfish 3.1.1 to TomEE. Now
> the problem is that this application contains a custom component which was
> unfortunately coded with hard dependencies on com.sun.faces classes (maven
> dependency jsf-impl).
>
> Now my question is how can i port this component in such a way that it is
> independent from any concrete JSF implementation (or at least in such a way
> that it works with MyFaces).
>
> Here's the component:
>
> import java.io.IOException;
> import java.util.Iterator;
> import java.util.Map;
>
> import javax.faces.component.UIComponent;
> import javax.faces.component.UINamingContainer;
> import javax.faces.component.ValueHolder;
> import javax.faces.context.FacesContext;
> import javax.faces.context.ResponseWriter;
> import javax.faces.convert.Converter;
> import javax.faces.model.SelectItem;
> import javax.faces.model.SelectItemGroup;
>
> import com.sun.faces.renderkit.Attribute;
> import com.sun.faces.renderkit.AttributeManager;
> import com.sun.faces.renderkit.RenderKitUtils;
> import com.sun.faces.renderkit.html_basic.MenuRenderer;
> import com.sun.faces.util.RequestStateManager;
> import com.sun.faces.util.Util;
>
> /**
> * {@inheritDoc}.
> */
> public class CustomSelectManyCheckboxListRenderer extends MenuRenderer
> {
> /** {@inheritDoc}. */
> private static final Attribute[] ATTRIBUTES =
> AttributeManager.getAttributes(AttributeManager.Key.SELECTMANYCHECKBOX);
> /** Representing the border string. */
> private static final String BORDER = "border";
> /** Representing the tr string. */
> private static final String TR = "tr";
> /** Representing the td string. */
> private static final String TD = "td";
> /** Representing the label string. */
> private static final String LABEL = "label";
> /** Representing the newline string. */
> private static final String NEWLINE = "\n";
> /** Representing the tab string. */
> private static final String TAB = "\t";
> /** Representing the class string. */
> private static final String CLASS = "class";
> /** Representing the style string. */
> private static final String STYLE = "style";
> /** Representing the valign string. */
> private static final String VALIGN = "valign";
>
>
> // -- Public
> Methods
>
>
> @Override
> public void encodeEnd(FacesContext context, UIComponent component)
> throws IOException
> {
>
> rendererParamsNotNull(context, component);
>
> if (!shouldEncode(component))
> {
> return;
> }
>
> ResponseWriter writer = context.getResponseWriter();
> assert (writer != null);
>
> String alignStr;
> Object borderObj;
> boolean alignVertical = false;
> int border = 0;
>
>
>
> if (null != component.getAttributes().get("layout"))
> {
> alignStr = (String) component.getAttributes().get("layout");
> alignVertical = alignStr.equalsIgnoreCase("pageDirection");
> }
>
> if (null != component.getAttributes().get(BORDER))
> {
> borderObj = component.getAttributes().get(BORDER);
> border = (Integer) borderObj;
> }
>
> Converter converter = null;
> if (component instanceof ValueHolder)
> {
> converter = ((ValueHolder)component).getConverter();
> }
>
> renderBeginText(component, border, alignVertical, context, true);
>
> Iterator items =
> RenderKitUtils.getSelectItems(context, componen
Re: Problems with a custom component when migrating from Glassfish(mojarra) to TomEE
in tomee you can also use mojarra but I'd just keep my component
portable with myfaces if possible
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-13 13:23 GMT+01:00 Thomas Andraschko :
> I don't think that anyone will port your complete code and give you a
> complete solution ;)
>
> The biggest problem is AFAIR that the renderer implementations are not in
> the API packages. So you have to rebuild all this functionality without
> dependencies to the Impl.
>
> e.g.
> Attribute,AttributeManager -> String[] with attribute namens
> Move all the utils functions to your own code (Util.componentIsDisabled,
> RenderKitUtils.getSelectItems. etc.)
>
> The most code doesn't really depent on the IMPL code.
>
>
> 2014-02-13 12:44 GMT+01:00 Rene Perschon :
>
>> Hi everyone!
>>
>> I'm currently migrating an application from Glassfish 3.1.1 to TomEE. Now
>> the problem is that this application contains a custom component which was
>> unfortunately coded with hard dependencies on com.sun.faces classes (maven
>> dependency jsf-impl).
>>
>> Now my question is how can i port this component in such a way that it is
>> independent from any concrete JSF implementation (or at least in such a way
>> that it works with MyFaces).
>>
>> Here's the component:
>>
>> import java.io.IOException;
>> import java.util.Iterator;
>> import java.util.Map;
>>
>> import javax.faces.component.UIComponent;
>> import javax.faces.component.UINamingContainer;
>> import javax.faces.component.ValueHolder;
>> import javax.faces.context.FacesContext;
>> import javax.faces.context.ResponseWriter;
>> import javax.faces.convert.Converter;
>> import javax.faces.model.SelectItem;
>> import javax.faces.model.SelectItemGroup;
>>
>> import com.sun.faces.renderkit.Attribute;
>> import com.sun.faces.renderkit.AttributeManager;
>> import com.sun.faces.renderkit.RenderKitUtils;
>> import com.sun.faces.renderkit.html_basic.MenuRenderer;
>> import com.sun.faces.util.RequestStateManager;
>> import com.sun.faces.util.Util;
>>
>> /**
>> * {@inheritDoc}.
>> */
>> public class CustomSelectManyCheckboxListRenderer extends MenuRenderer
>> {
>> /** {@inheritDoc}. */
>> private static final Attribute[] ATTRIBUTES =
>> AttributeManager.getAttributes(AttributeManager.Key.SELECTMANYCHECKBOX);
>> /** Representing the border string. */
>> private static final String BORDER = "border";
>> /** Representing the tr string. */
>> private static final String TR = "tr";
>> /** Representing the td string. */
>> private static final String TD = "td";
>> /** Representing the label string. */
>> private static final String LABEL = "label";
>> /** Representing the newline string. */
>> private static final String NEWLINE = "\n";
>> /** Representing the tab string. */
>> private static final String TAB = "\t";
>> /** Representing the class string. */
>> private static final String CLASS = "class";
>> /** Representing the style string. */
>> private static final String STYLE = "style";
>> /** Representing the valign string. */
>> private static final String VALIGN = "valign";
>>
>>
>> // -- Public
>> Methods
>>
>>
>> @Override
>> public void encodeEnd(FacesContext context, UIComponent component)
>> throws IOException
>> {
>>
>> rendererParamsNotNull(context, component);
>>
>> if (!shouldEncode(component))
>> {
>> return;
>> }
>>
>> ResponseWriter writer = context.getResponseWriter();
>> assert (writer != null);
>>
>> String alignStr;
>> Object borderObj;
>> boolean alignVertical = false;
>> int border = 0;
>>
>>
>>
>> if (null != component.getAttributes().get("layout"))
>> {
>> alignStr = (String) component.getAttributes().get("layout");
>> alignVertical = alignStr.equalsIgnoreCase("pageDirection");
>> }
>>
>> if (null != component.getAttributes().get(BORDER))
>> {
>> borderObj = component.getAttributes().get(BORDER);
>> border = (Integer) borderObj;
>> }
>>
>> Converter converter = null;
>> if (component instanceof ValueHolder)
>> {
>> converter = ((ValueHolder)component).getConverter();
>> }
>>
>> renderBeginText(component, border, alignVertical, context, true);
>>
>> Iterator items =
>> RenderKitUtils.getSelectItems(context, component);
>>
>> Object currentSelections = getCurrentSelectedValues(component);
>> Object[] submittedValues = getSubmittedSelectedValues(component);
>> Map attributes = component.getAttributes();
>> OptionComponentInfo optionInfo =
>> new OptionComponentInfo((String)
>> attributes.get("d
Re: Problems with a custom component when migrating from Glassfish(mojarra) to TomEE
I don't think that anyone will port your complete code and give you a
complete solution ;)
The biggest problem is AFAIR that the renderer implementations are not in
the API packages. So you have to rebuild all this functionality without
dependencies to the Impl.
e.g.
Attribute,AttributeManager -> String[] with attribute namens
Move all the utils functions to your own code (Util.componentIsDisabled,
RenderKitUtils.getSelectItems. etc.)
The most code doesn't really depent on the IMPL code.
2014-02-13 12:44 GMT+01:00 Rene Perschon :
> Hi everyone!
>
> I'm currently migrating an application from Glassfish 3.1.1 to TomEE. Now
> the problem is that this application contains a custom component which was
> unfortunately coded with hard dependencies on com.sun.faces classes (maven
> dependency jsf-impl).
>
> Now my question is how can i port this component in such a way that it is
> independent from any concrete JSF implementation (or at least in such a way
> that it works with MyFaces).
>
> Here's the component:
>
> import java.io.IOException;
> import java.util.Iterator;
> import java.util.Map;
>
> import javax.faces.component.UIComponent;
> import javax.faces.component.UINamingContainer;
> import javax.faces.component.ValueHolder;
> import javax.faces.context.FacesContext;
> import javax.faces.context.ResponseWriter;
> import javax.faces.convert.Converter;
> import javax.faces.model.SelectItem;
> import javax.faces.model.SelectItemGroup;
>
> import com.sun.faces.renderkit.Attribute;
> import com.sun.faces.renderkit.AttributeManager;
> import com.sun.faces.renderkit.RenderKitUtils;
> import com.sun.faces.renderkit.html_basic.MenuRenderer;
> import com.sun.faces.util.RequestStateManager;
> import com.sun.faces.util.Util;
>
> /**
> * {@inheritDoc}.
> */
> public class CustomSelectManyCheckboxListRenderer extends MenuRenderer
> {
> /** {@inheritDoc}. */
> private static final Attribute[] ATTRIBUTES =
> AttributeManager.getAttributes(AttributeManager.Key.SELECTMANYCHECKBOX);
> /** Representing the border string. */
> private static final String BORDER = "border";
> /** Representing the tr string. */
> private static final String TR = "tr";
> /** Representing the td string. */
> private static final String TD = "td";
> /** Representing the label string. */
> private static final String LABEL = "label";
> /** Representing the newline string. */
> private static final String NEWLINE = "\n";
> /** Representing the tab string. */
> private static final String TAB = "\t";
> /** Representing the class string. */
> private static final String CLASS = "class";
> /** Representing the style string. */
> private static final String STYLE = "style";
> /** Representing the valign string. */
> private static final String VALIGN = "valign";
>
>
> // -- Public
> Methods
>
>
> @Override
> public void encodeEnd(FacesContext context, UIComponent component)
> throws IOException
> {
>
> rendererParamsNotNull(context, component);
>
> if (!shouldEncode(component))
> {
> return;
> }
>
> ResponseWriter writer = context.getResponseWriter();
> assert (writer != null);
>
> String alignStr;
> Object borderObj;
> boolean alignVertical = false;
> int border = 0;
>
>
>
> if (null != component.getAttributes().get("layout"))
> {
> alignStr = (String) component.getAttributes().get("layout");
> alignVertical = alignStr.equalsIgnoreCase("pageDirection");
> }
>
> if (null != component.getAttributes().get(BORDER))
> {
> borderObj = component.getAttributes().get(BORDER);
> border = (Integer) borderObj;
> }
>
> Converter converter = null;
> if (component instanceof ValueHolder)
> {
> converter = ((ValueHolder)component).getConverter();
> }
>
> renderBeginText(component, border, alignVertical, context, true);
>
> Iterator items =
> RenderKitUtils.getSelectItems(context, component);
>
> Object currentSelections = getCurrentSelectedValues(component);
> Object[] submittedValues = getSubmittedSelectedValues(component);
> Map attributes = component.getAttributes();
> OptionComponentInfo optionInfo =
> new OptionComponentInfo((String)
> attributes.get("disabledClass"),
> (String)
> attributes.get("enabledClass"),
> (String)
> attributes.get("unselectedClass"),
> (String)
> attributes.get("selectedClass"),
> Util.componentIsDisabled(component),
> isHideNoSelection(component));
> int idx = -1;
> while (ite
