yes, ok, let's wait!
JDK 1.5 in the sandbox right now is not a good idea, I think.
regards,
Martin
On 9/7/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> Well doing a branch for the few classes I have right now really isn't worth
> it.
>
> Maybe it's better to hold on this until we start JSF 1.2.
>
>
> On Wed, 2005-09-07 at 00:21 +0200, Bruno Aranda wrote:
> I do not thing that including JDK5.0 code in the sandbox and not in
> the rest is a good idea. It might create confusion... maybe we could
> add a JDK5.0 branch to the sandbox SVN tree and then we would keep
> your need code, but, IMO valid JDK1.4 code should be everywhere...
>
> Bruno
>
> P.S Currently, I am developing all my projects in JDK5.0. I have to
> think twice when programming for myfaces! ;-)
>
> 2005/9/7, Sylvain Vieujot <[EMAIL PROTECTED]>:
> > I didn't mean to include it in the sandbox and hope to refactor it later.
> > I meant to add it to the sandbox, and to move it to tomahawk only when we
> > accept JSE5 code in tomahawk (which is required for JSF 1.2 if I'm not
> > wrong).
> > The point is that be refactoring those classes, we lose a lot of safety,
> so
> > I would prefer to either commit them to the sandbox if we accept JSE5 code
> > into it, or just hold them until we do.
> >
> > It's not crucial anyway, as those cases are still limited right now.
> >
> >
> > On Tue, 2005-09-06 at 17:34 -0400, Sean Schofield wrote:
> > IMO that's a bad idea. Why would you add it with JSE 5 to the sandbox
> > but chance it to 1.4 when moving to tomahawk? What would be the point
> > of that?
> > Why not refactor before adding to sandbox if this is the eventual plan?
> >
> > I'm not sure how I feel about requiring JSE 5 (I don't use it myself)
> > but I definitely don't think we should add stuff and hope to refactor
> > it later.
> >
> > sean
> >
> > On 9/6/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> > > Hello,
> > >
> > > I was about to commit the few Maps util classes I have when I realized
> > it's
> > > all Java 5 code (with many generics and a few annotations).
> > > Removing the generics would really be bad as those classes needs to be
> > > extended, and the generics add a lot of safety.
> > >
> > > For me it would be ok to add Java 5, and later to move it to tomahawk
> when
> > > we move to JSF 1.2, but I would need the approval of the others to do
> > that,
> > > as it would break the sandbox compilation on Java 1.4.
> > >
> > > What do you think ?
> > >
> > > Sylvain.
> > >
> > > On Tue, 2005-09-06 at 13:09 +0200, Martin Marinschek wrote:
> > > Yes...
> > >
> > > Let's put it there, and go on from this!
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 9/6/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> > > > Hello Martin,
> > > >
> > > > No, I never committed it.
> > > > I think a new package would be great, but where do you want to put it
> ?
> > > > The logic would be to have it first in the sandbox, and then move it
> > class
> > > > by class tomahawk.
> > > >
> > > > Maybe a better package name would be org.apache.myfaces.utils
> > > > as jsfutils is redundant with myfaces. I also dropped the tomahawk
> part
> > as
> > > > it would be in the sandbox first, but I'm not sure about this.
> > > >
> > > > If you agree, I can commit those classes to the sandbox's
> > > > org.apache.myfaces.utils package, and we can start from here.
> > > >
> > > > Sylvain.
> > > >
> > > >
> > > > On Tue, 2005-09-06 at 07:48 +0200, Martin Marinschek wrote:
> > > > Sylvain,
> > > >
> > > > did you ever get around to commit this stuff? I didn't find it in the
> > > > sources...
> > > >
> > > > I'd like to use that as an example for something I am writing on -
> > > > would be great if I could just point to the MyFaces sourcebase.
> > > >
> > > > How about a new package
> > > >
> > > > org apache myfaces tomahawk jsfutils
> > > >
> > > > We could also have the user contributions like the message-remembering
> > > > facilities and the newly added remember request-bean over redirect
> > > > facilities there...
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 5/11/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> > > > > I'm fine with that and find it simpler to have it in the trunk.
> > > > >
> > > > > I have a related question.
> > > > >
> > > > > Right now, I have done 2 little utilities that help me resolve small
> > > > > problems.
> > > > > They are 2 abstract implementations of Map : ActionMap and TestMap,
> > and
> > > I
> > > > > find them handy to use in many common cases.
> > > > >
> > > > > Here are 2 examples :
> > > > > 1) ActionMap : For example, when you have a list of file, and want
> to
> > > have
> > > > > a checkbox to delete a file, you just add the following code in your
> > > page
> > > > :
> > > > > <h:column>
> > > > > <h:selectBooleanCheckbox
> > value="#{pageFace.removeFileName[file.name]}"/>
> > > > > <h:outputText value="delete"/>
> > > > > </h:column>
> > > > >
> > > > >
> > > > > And in your backing bean : public ActionsMap getRemoveFileName(){
> > > > > return new ActionsMap(){
> > > > > @Override
> > > > > public void performAction(String fileName) {
> > > > > getFiles().remove( fileName );
> > > > > }
> > > > > };
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > > 2) TestMap : I use it to pass parameters to methods using a map, and
> > > > > getting a boolean result.
> > > > > For example, if you want to render a component if a user is in 2
> > roles,
> > > > the
> > > > > visibleOnUserRole isn't enough.
> > > > > So, in my backing bean, I have this method :
> > > > >
> > > > > public TestsMap getUserInRole(){
> > > > > return new TestsMap(){
> > > > > @Override
> > > > > public boolean getTest(String roleName) {
> > > > > return getHttpServletRequest().isUserInRole(
> roleName
> > > );
> > > > > }
> > > > > };
> > > > > }
> > > > >
> > > > > And now, I can do any test I want in EL :
> > > > > #{myBean.isUserInRole['Accountant'] &&
> > > myBean.isUserInRole['CountryUnit']}
> > > > >
> > > > > It's quite limited now, but due to the limitations of the EL, small
> > > > > utilities like that can help.
> > > > > My suggestion is to do a utilities library (similar to commons.lang,
> > > with
> > > > > StringUtils, ...) for EL, and maybe for JSF if more good candidates
> > > > emerge.
> > > > >
> > > > > So, I wonder first if you guys feels this is of any use to include
> > this
> > > in
> > > > > MyFaces, and if so, how do we handle that ?
> > > > > Those aren't components, but should we do a sandbox for libraries
> to,
> > or
> > > > > just an additional myfaces-utilities.jar ????
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Sylvain.
> > > > >
> > > > >
> > > > > On Wed, 2005-05-11 at 11:41 -0700, Grant Smith wrote:
> > > > >
> > > > > I recall correctly, the consensus was to have a "sandbox subproject"
> > > > > for new components. I would like to propose a simpler solution: Why
> > not
> > > > > have the sandbox as a subdirectory of the existing project. Then we
> > can
> > > > > just specify all "s:" components as sandbox components until they
> are
> > > > > completely accepted by the community. At that time they can become
> > "x:"
> > > > > components.
> > > > >
> > > > > Would this satisfy the ASF's requirement for "All New Components
> Must
> > Go
> > > > > Through the Incubator" ? Hopefully...
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German
