Re: Facelet support in MyFaces

[Mike Kienenberger <mk...@gmail.com>]

It probably depends on your definition of minor flaws.  :)

In my opinion, they both work together well enough, but it's possible
that people who don't use facelets the same way that I do may have
problems I have not encountered.

The only issue I'm aware of that might be causing problems for
facelets users is this one, but I haven't been affected by it, but I
tend to manually assign id values for most components.

http://issues.apache.org/jira/browse/MYFACES-833

The rest of the issues are component-specific (ie, attribute naming
mismatches between tree2 tag and component, derived attributes in
tree, method binding attributes [mb attrs have to be solved with a
custom facelets tag handler]) and can be solved with a facelets tag
handler or by creating "cleaner" component/tag interactions
(consistent attribute names, no logic in the tag class).

Hopefully, Jacob or Adam can jump in if I've missed any other
outstanding issues.

On 12/17/05, Martin Marinschek <ma...@gmail.com> wrote:
> @facelets working with MyFaces:
>
> Well, I was under the impression (by what Jacob and Adam pointed out)
> that Myfaces and Facelets didn't work together exceptionally good.
>
> So you say it works and there are just some minor flaws?
>
> regards,
>
> Maritn
>
> So you are saying it works but
> On 12/17/05, Martin Marinschek <ma...@gmail.com> wrote:
> > Yes, they are still in old jsp format.
> >
> > We should rework them in jspx anyways at some point in time.
> >
> > regards,
> >
> > Martin
> >
> > On 12/16/05, Mike Kienenberger <mk...@gmail.com> wrote:
> > > On 12/14/05, Martin Marinschek <ma...@gmail.com> wrote:
> > > > we haven't as we still have some open bugs which prevent working
> > > > Facelets perfectly with MyFaces. So this is a hen-egg problem. If we
> > > > got rid of those bugs, we'd use Facelets more, if Facelets was used
> > > > more, there might be someone inclined to get rid of those bugs ;).
> > >
> > > As facelets end-user #1 (so I'm told), I can say that facelets has
> > > worked, and continues to work, fine with MyFaces (I have used MyFaces
> > > and facelets exclusively the last 6 months).   There's a few tomahawk
> > > and sandbox components out there that need better facelet support, and
> > > hopefully I can be instrumental in getting that developed, as time
> > > permits, but most of them work "as-is" right now.
> > >
> > > One of the things I'd like to see happen is to have the facelets
> > > taglib.xml files generated automatically for the tomahawk and sandbox
> > > components.   That's probably going to require getting code generation
> > > working again, and I haven't had a chance to review that part of the
> > > project.  I think the Shale/Clay folks would like to see similar
> > > functionality provided for their view handler.
> > >
> > > The other thing that will be helpful is to get some facelet component
> > > tag handler classes written and added to the myfaces codebase for
> > > those components that have non-ActionSource method bindings (or
> > > non-pass-through Tag code behavior).   This will require a build-time
> > > dependency on facelets for tomahawk and sandbox, so it might need to
> > > be done in such a way as to make building these classes optional.
> > >
> > > And, of course, we need some examples.   As Adam has mentioned,
> > > facelet xhtml pages are so close to jspx pages that often times you
> > > can "convert" between the two simply by renaming them.   Unfortunately
> > > (and I haven't looked at the examples in detail recently, so I could
> > > be wrong), the examples are mostly in jsp, and contain a lot of
> > > embedded scriptlets.
> > >
> > > -Mike
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>

Re: Facelet support in MyFaces

[Jacob Hookom <ja...@hookom.net>]

Component Identifiers are always a tricky issue, so we possibly just 
need to 'balance' out our strategies for correcting this.

--

Both Kito Mann and Adam Winer suggested that I not automatically assign 
generated IDs on every call (which was a catch all for duplicate ID 
issues).  So I modified the logic of Facelet's ComponentHandler to 
simply not assign one if there wasn't an ID attr in the page, but then 
MyFaces logged warnings that *not* assigning one was 'bad'.  According 
to the spec, this should be allowed.

--

Pertaining to Issue #833 below, I was aware of the fact that Facelets 
needed to do state-write behind. It's finally implemented so it only 
stores the state after rendering-- no matter what pages/components were 
included or rendered.  This works *great* with JSF 1.2 RI and kind of 
with MyFaces-- only because the f:view tag was doing that extra logic.

--

The biggy with Facelets is around UIComponents.  I took the approach 
that JSP Tags are just extra weight and there shouldn't be a need to 
write adaptors to assign state-- simple enough?  Facelets just takes the 
approach of condensing all of the logic in JSPs UIComponentTag into some 
*very* simple rules.

Where this automatic assignment falls apart with specialized components 
is when there is coercing between attr names and UIComponent property 
names.  Even with Facelets, this is easily solvable by implementing a 
ComponentTagHandler and overriding:

protected MetaRuleset createMetaRuleset(Class type) {
   return super.createMetaRuleset(type).alias("class", "styleClass");
}

It's all very straight forward and was driven by Adam's expectations for 
integrating all of ADF's Components here:

https://facelets.dev.java.net/servlets/ReadMsg?list=users&msgNo=326

https://facelets.dev.java.net/source/browse/facelets/contrib/1.4/adf

--

Cheers!

Jacob



Mike Kienenberger wrote:

>It probably depends on your definition of minor flaws.  :)
>
>In my opinion, they both work together well enough, but it's possible
>that people who don't use facelets the same way that I do may have
>problems I have not encountered.
>
>The only issue I'm aware of that might be causing problems for
>facelets users is this one, but I haven't been affected by it, but I
>tend to manually assign id values for most components.
>
>http://issues.apache.org/jira/browse/MYFACES-833
>
>The rest of the issues are component-specific (ie, attribute naming
>mismatches between tree2 tag and component, derived attributes in
>tree, method binding attributes [mb attrs have to be solved with a
>custom facelets tag handler]) and can be solved with a facelets tag
>handler or by creating "cleaner" component/tag interactions
>(consistent attribute names, no logic in the tag class).
>
>Hopefully, Jacob or Adam can jump in if I've missed any other
>outstanding issues.
>
>On 12/17/05, Martin Marinschek <ma...@gmail.com> wrote:
>  
>
>>@facelets working with MyFaces:
>>
>>Well, I was under the impression (by what Jacob and Adam pointed out)
>>that Myfaces and Facelets didn't work together exceptionally good.
>>
>>So you say it works and there are just some minor flaws?
>>
>>regards,
>>
>>Maritn
>>
>>So you are saying it works but
>>On 12/17/05, Martin Marinschek <ma...@gmail.com> wrote:
>>    
>>
>>>Yes, they are still in old jsp format.
>>>
>>>We should rework them in jspx anyways at some point in time.
>>>
>>>regards,
>>>
>>>Martin
>>>
>>>On 12/16/05, Mike Kienenberger <mk...@gmail.com> wrote:
>>>      
>>>
>>>>On 12/14/05, Martin Marinschek <ma...@gmail.com> wrote:
>>>>        
>>>>
>>>>>we haven't as we still have some open bugs which prevent working
>>>>>Facelets perfectly with MyFaces. So this is a hen-egg problem. If we
>>>>>got rid of those bugs, we'd use Facelets more, if Facelets was used
>>>>>more, there might be someone inclined to get rid of those bugs ;).
>>>>>          
>>>>>
>>>>As facelets end-user #1 (so I'm told), I can say that facelets has
>>>>worked, and continues to work, fine with MyFaces (I have used MyFaces
>>>>and facelets exclusively the last 6 months).   There's a few tomahawk
>>>>and sandbox components out there that need better facelet support, and
>>>>hopefully I can be instrumental in getting that developed, as time
>>>>permits, but most of them work "as-is" right now.
>>>>
>>>>One of the things I'd like to see happen is to have the facelets
>>>>taglib.xml files generated automatically for the tomahawk and sandbox
>>>>components.   That's probably going to require getting code generation
>>>>working again, and I haven't had a chance to review that part of the
>>>>project.  I think the Shale/Clay folks would like to see similar
>>>>functionality provided for their view handler.
>>>>
>>>>The other thing that will be helpful is to get some facelet component
>>>>tag handler classes written and added to the myfaces codebase for
>>>>those components that have non-ActionSource method bindings (or
>>>>non-pass-through Tag code behavior).   This will require a build-time
>>>>dependency on facelets for tomahawk and sandbox, so it might need to
>>>>be done in such a way as to make building these classes optional.
>>>>
>>>>And, of course, we need some examples.   As Adam has mentioned,
>>>>facelet xhtml pages are so close to jspx pages that often times you
>>>>can "convert" between the two simply by renaming them.   Unfortunately
>>>>(and I haven't looked at the examples in detail recently, so I could
>>>>be wrong), the examples are mostly in jsp, and contain a lot of
>>>>embedded scriptlets.
>>>>
>>>>-Mike
>>>>
>>>>        
>>>>
>>>--
>>>
>>>http://www.irian.at
>>>
>>>Your JSF powerhouse -
>>>JSF Consulting, Development and
>>>Courses in English and German
>>>
>>>Professional Support for Apache MyFaces
>>>
>>>      
>>>
>>--
>>
>>http://www.irian.at
>>
>>Your JSF powerhouse -
>>JSF Consulting, Development and
>>Courses in English and German
>>
>>Professional Support for Apache MyFaces
>>
>>    
>>
>
>  
>


-- 
Jacob Hookom - Minneapolis
--------------------------
http://hookom.blogspot.com