You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Andrew Robinson <an...@gmail.com> on 2006/05/09 22:05:28 UTC
MyFaces support for Facelets
Until now, most people are using the WIKI[1] for getting myfaces to
work with facelets. I was wondering if we want to make MyFaces include
support for facelets natively. This should be able to be done in such
a way to prevent problems for those that do not use facelets.
Option 1)
Add everything to tomahawk.jar including the TagHandler classes and
taglib.xml file(s).
This is easiest, and will not cause issues since non-facelet users
will not be using those classes, and therefore if they don't have
facelets in their classpath, it shouldn't matter.
Option 2)
Create a new myfaces jar file (tomahawk-facelets-1.1.2.jar for
example) that contains only the code and configuration necessary to
"plug" tomahawk into facelets.
This is possibly more elegant but more of a pain to setup.
Option 3)
Maintain all this at jsf-comp.
This works, but new users may not know about jsf-comp and it is harder
to stay in sync with facelet and myfaces version changes (since it is
not tied into the release cycle).
Since facelets hasn't changed the taglib.xml structure at all, facelet
version should not be a major issue. This would also make issues like
what tree2 had a mute point since we could include component handlers
built in to translate any "non-standard" logic in the Tag classes.
This methodology could be applied to the sandbox as well. Once there
is some code in SVN I would think myfaces developers could easily
maintain their configuration for their components as well since there
would be examples from other components to learn from (so even
developers without facelets experience shouldn't have any issues).
What do you think?
-Andrew
[1] http://wiki.apache.org/myfaces/Use_Facelets_with_Tomahawk
Re: MyFaces support for Facelets
Posted by Ryan Wynn <bi...@gmail.com>.
I like the idea of packaged support for Facelets. Along the same
lines I also really like the idea of packaged support for Shale Clay.
http://issues.apache.org/jira/browse/TOMAHAWK-70
packaging could follow suit with the facelets solution.
Re: MyFaces support for Facelets
Posted by Mike Kienenberger <mk...@gmail.com>.
On 5/9/06, Mike Kienenberger <mk...@gmail.com> wrote:
> I think we'll want to make it a separate jar and project because
> facelets depends on JSF 1.2 RI and the Glassfish EL jars. And maybe
> JSP 2.1 as well. Those don't need to be dependencies for standard
> tomahawk use.
In case it's not clear, that's my vote for option 2 :-)
Re: Too many components (ADF?)
Posted by Martin Marinschek <ma...@gmail.com>.
I think you should post that to the ADF faces user list.
regards,
Martin
On 5/16/06, Mark Millman <ma...@thecmsdkgroup.com> wrote:
> The following describes a problem I am having using Oracle ADF as
> shipped with the JDevStudio final release 10.1.3.0.4. I've posted the
> problem to the Oracle Jdeveloper Forum and got an immediate show of
> interest from Oracle but nothing since then in terms of a clue as to
> whether this is a solvable problem or not. I'd be interested to know if
> anyone in the non-ADF community has run into a similar problem and
> whether anyone from Oracle can tell me if this is an ADF bug or a
> JDeveloper bug and if there is a work-around (other than just reducing
> the number of components on a page).
>
> My page has finally gotten so complex that the stack overflows and the
> application just aborts. I can remove a couple of components and the
> page works fine. It doesn't seem to matter which components I remove;
> when I navigate to the page the following appears in my Embedded OC4J
> Server log.
>
> Debugger connection to debuggee process has been lost.
> Process exited.
> Debugger disconnected from local process.
>
> The _MyPage_jspx.java file is over 500K and the class file is about
> 110K. If I remove some components and get the total _MyPage_jspx.java
> file under 500K then the page works again.
>
> The page includes a lot of application controls and a number of tables
> that are used to display and edit attribute data. Most of these tables
> include nested tables inside of their detailStamps. Rows in a table of
> streets have tables of sites. This is where things start to fail.
>
> Sometimes (but not always) I get a message that tells me that could not
> find the StackOverflowError class so I have tried adding a -Xss1024k
> option to my Java options but this didn't help; neither did -Xss2048k.
>
> I am highly confident that the problem is not caused by the code itself
> as I can remove any panelGroup or panelForm set on the page and it
> works. I put any back and it fails. It is just too many components.
> Everything compiles fine but JDeveloper just disconnects from the
> application when the page is opened.
>
> The following is some simple JSP code that demonstrates the problem.
>
> Include-0.jspf
>
> <af:panelBox text="Bottom include file has 3 panelForms" >
> <af:panelHorizontal>
> <af:panelForm rows="1" maxColumns="1">
> <af:inputText label="Lorem ipsum" rows="3" wrap="true"
> readOnly="true"
> value="Proin orci. Suspendisse cursus lobortis
> magna. Vivamus id tortor. Phasellus consectetuer, quam sit amet laoreet
> ultrices, tortor leo aliquet turpis." />
> <af:inputText label="Lorem ipsum" rows="3" wrap="true"
> readOnly="true"
> value="Proin orci. Suspendisse cursus lobortis
> magna. Vivamus id tortor. Phasellus consectetuer, quam sit amet laoreet
> ultrices, tortor leo aliquet turpis." />
> <af:inputText label="Lorem ipsum" rows="3" wrap="true"
> readOnly="true"
> value="Proin orci. Suspendisse cursus lobortis
> magna. Vivamus id tortor. Phasellus consectetuer, quam sit amet laoreet
> ultrices, tortor leo aliquet turpis." />
> </af:panelForm>
> <af:panelForm rows="1" maxColumns="1">
> <af:inputText label="Lorem ipsum" rows="3" wrap="true"
> readOnly="true"
> value="Proin orci. Suspendisse cursus lobortis
> magna. Vivamus id tortor. Phasellus consectetuer, quam sit amet laoreet
> ultrices, tortor leo aliquet turpis." />
> <af:inputText label="Lorem ipsum" rows="3" wrap="true"
> readOnly="true"
> value="Proin orci. Suspendisse cursus lobortis
> magna. Vivamus id tortor. Phasellus consectetuer, quam sit amet laoreet
> ultrices, tortor leo aliquet turpis." />
> <af:inputText label="Lorem ipsum" rows="3" wrap="true"
> readOnly="true"
> value="Proin orci. Suspendisse cursus lobortis
> magna. Vivamus id tortor. Phasellus consectetuer, quam sit amet laoreet
> ultrices, tortor leo aliquet turpis." />
> </af:panelForm>
> <af:panelForm rows="1" maxColumns="1">
> <af:inputText label="Lorem ipsum" rows="3" wrap="true"
> readOnly="true"
> value="Proin orci. Suspendisse cursus lobortis
> magna. Vivamus id tortor. Phasellus consectetuer, quam sit amet laoreet
> ultrices, tortor leo aliquet turpis." />
> <af:inputText label="Lorem ipsum" rows="3" wrap="true"
> readOnly="true"
> value="Proin orci. Suspendisse cursus lobortis
> magna. Vivamus id tortor. Phasellus consectetuer, quam sit amet laoreet
> ultrices, tortor leo aliquet turpis." />
> <af:inputText label="Lorem ipsum" rows="3" wrap="true"
> readOnly="true"
> value="Proin orci. Suspendisse cursus lobortis
> magna. Vivamus id tortor. Phasellus consectetuer, quam sit amet laoreet
> ultrices, tortor leo aliquet turpis." />
> </af:panelForm>
> </af:panelHorizontal>
> </af:panelBox>
>
>
> I included this in another jspf file
>
> Include-1.jspf
>
> <af:panelBox text="Include-1.jspf includes Include-0.jspf 5 times.">
> <jsp:directive.include file="/Include-0.jspf" />
> <jsp:directive.include file="/Include-0.jspf" />
> <jsp:directive.include file="/Include-0.jspf" />
> <jsp:directive.include file="/Include-0.jspf" />
> <jsp:directive.include file="/Include-0.jspf" />
> </af:panelBox>
>
>
> I include that in another jspf
>
> Include-2.jspf
>
> <af:panelBox text="Include-2.jspf includes Include-1.jspf 5 times.">
> <jsp:directive.include file="/Include-1.jspf" />
> <jsp:directive.include file="/Include-1.jspf" />
> <jsp:directive.include file="/Include-1.jspf" />
> <jsp:directive.include file="/Include-1.jspf" />
> <jsp:directive.include file="/Include-1.jspf" />
> </af:panelBox>
>
>
> And that is referenced by my jspx page.
>
> TooManyComponents.jspx
>
> <?xml version='1.0' encoding='windows-1252'?>
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="1.2"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:af="http://xmlns.oracle.com/adf/faces"
> xmlns:afh="http://xmlns.oracle.com/adf/faces/html">
> <jsp:text>
> <![CDATA[ ><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
> Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> ]]>
> </jsp:text>
> <jsp:directive.page contentType="text/html;charset=windows-1252"/>
> <f:view>
> <afh:script source="/jscript/view_tools.js"/>
> <af:document rendered="false">
> <af:form id="notloggedin">
> <af:panelPage title="This never happens but it mirrors my
> problem layour">
> <jsp:directive.include file="header.jspf"/>
> <af:commandMenuItem text="You are not logged in. Please click
> this message to be re-directed to the Login Page" action="login"/>
> </af:panelPage>
> </af:form>
> </af:document>
> <af:document rendered="true">
> <af:form id="loggedin">
> <af:panelPage title="Too much of a good thing?">
> <jsp:directive.include file="/header.jspf"/>
> <jsp:directive.include file="/Include-2.jspf" />
> </af:panelPage>
> </af:form>
> </af:document>
> </f:view>
> </jsp:root>
>
>
> This particular setup yeilded me the following error
>
> Fatal error: Cannot find class java/lang/StackOverflowErrorProcess
> exited.Debugger disconnected from local process.
>
>
> If I put a second
> <jsp:directive.include file="/Include-2.jspf" />
> in my jspx file I get the following compile time error.
>
> Error: code segment of method
> _jspService(javax.servlet.http.HttpServletRequest,
> javax.servlet.http.HttpServletResponse) too large
>
>
> If I remove one of the jsp:include directives from my Include-1.jspf so
> that it reads as follows:
>
> <af:panelBox text="Include-1.jspf includes Include-0.jspf 4 times.">
> <jsp:directive.include file="/Include-0.jspf" />
> <jsp:directive.include file="/Include-0.jspf" />
> <jsp:directive.include file="/Include-0.jspf" />
> <jsp:directive.include file="/Include-0.jspf" />
> </af:panelBox>
>
> The application works.
>
> I took all the JDeveloperStudio defaults for creating my project.
>
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Calendar bug in 1.1.1?
Posted by Cosma Colanicchia <co...@gmail.com>.
See this thread:
http://thread.gmane.org/gmane.comp.jakarta.myfaces.user/19435/focus=19435
Cosma
2006/5/16, Dennis Virtudazo <de...@yahoo.com>:
>
> Has anyone seen this bug(?) in myfaces 1.1.1. The
> InputCalendar control always generates a valueChange
> event and returns a date that is 1 day less than what
> is entered/displayed on the jsp page.
>
> I am using just a simple flavor InputCalendar with no
> timezones.
>
> This doesn't happen in 1.0.9.
>
> Any suggestions please.
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
Calendar bug in 1.1.1?
Posted by Dennis Virtudazo <de...@yahoo.com>.
Has anyone seen this bug(?) in myfaces 1.1.1. The
InputCalendar control always generates a valueChange
event and returns a date that is 1 day less than what
is entered/displayed on the jsp page.
I am using just a simple flavor InputCalendar with no
timezones.
This doesn't happen in 1.0.9.
Any suggestions please.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: MyFaces support for Facelets
Posted by Sean Schofield <se...@gmail.com>.
Part of the release notes will be what version of facelets that
particular tomahawk release is compatible with. We will probably just
try to keep in sync with the most current stable facelets release.
You could always rebuild from SVN and switch in a prior (or custom)
taglib xml file.
Plus if Adam is correct, it doesn't sound like it will be much of an issue.
Sean
On 5/15/06, Adam Winer <aw...@gmail.com> wrote:
> Andrew,
>
> I don't see any changes coming in the tag handler API or XML format,
> and just asked Jacob, who agrees.
>
> -- Adam
>
>
> On 5/15/06, Andrew Robinson <an...@gmail.com> wrote:
> > What if there is a need for a different JAR for different facelets versions?
> > For example, if Jacob changed the tag handler API in Facelets 1.2, then the
> > code would be different for Facelets 1.1 and 1.2. This is the big reason I
> > see for having the Jars separate.
> >
> > -Andrew
> >
> >
> > On 5/15/06, Sean Schofield <se...@gmail.com> wrote:
> > > > I don't see these as significant advantages to making it a separate
> > > > JAR. None of these should be marked as required dependencies for
> > > > standard tomahawk use - they should all be marked as "provided"
> > > > scope, which avoids the issue.
> > >
> > > I agreee. Why not include the facelets config file in the META-INF of
> > > the regular old tomahawk.jar? It certainly doesn't hurt anyone not
> > > using facelets and it would be a major incentive to use MyFaces
> > > components if they were able to be used with facelets out of the box.
> > >
> > > > -- Adam
> > >
> > > Sean
> > >
> >
> >
>
Too many components (ADF?)
Posted by Mark Millman <ma...@thecmsdkgroup.com>.
The following describes a problem I am having using Oracle ADF as
shipped with the JDevStudio final release 10.1.3.0.4. I've posted the
problem to the Oracle Jdeveloper Forum and got an immediate show of
interest from Oracle but nothing since then in terms of a clue as to
whether this is a solvable problem or not. I'd be interested to know if
anyone in the non-ADF community has run into a similar problem and
whether anyone from Oracle can tell me if this is an ADF bug or a
JDeveloper bug and if there is a work-around (other than just reducing
the number of components on a page).
My page has finally gotten so complex that the stack overflows and the
application just aborts. I can remove a couple of components and the
page works fine. It doesn't seem to matter which components I remove;
when I navigate to the page the following appears in my Embedded OC4J
Server log.
Debugger connection to debuggee process has been lost.
Process exited.
Debugger disconnected from local process.
The _MyPage_jspx.java file is over 500K and the class file is about
110K. If I remove some components and get the total _MyPage_jspx.java
file under 500K then the page works again.
The page includes a lot of application controls and a number of tables
that are used to display and edit attribute data. Most of these tables
include nested tables inside of their detailStamps. Rows in a table of
streets have tables of sites. This is where things start to fail.
Sometimes (but not always) I get a message that tells me that could not
find the StackOverflowError class so I have tried adding a -Xss1024k
option to my Java options but this didn't help; neither did -Xss2048k.
I am highly confident that the problem is not caused by the code itself
as I can remove any panelGroup or panelForm set on the page and it
works. I put any back and it fails. It is just too many components.
Everything compiles fine but JDeveloper just disconnects from the
application when the page is opened.
The following is some simple JSP code that demonstrates the problem.
Include-0.jspf
<af:panelBox text="Bottom include file has 3 panelForms" >
<af:panelHorizontal>
<af:panelForm rows="1" maxColumns="1">
<af:inputText label="Lorem ipsum" rows="3" wrap="true"
readOnly="true"
value="Proin orci. Suspendisse cursus lobortis
magna. Vivamus id tortor. Phasellus consectetuer, quam sit amet laoreet
ultrices, tortor leo aliquet turpis." />
<af:inputText label="Lorem ipsum" rows="3" wrap="true"
readOnly="true"
value="Proin orci. Suspendisse cursus lobortis
magna. Vivamus id tortor. Phasellus consectetuer, quam sit amet laoreet
ultrices, tortor leo aliquet turpis." />
<af:inputText label="Lorem ipsum" rows="3" wrap="true"
readOnly="true"
value="Proin orci. Suspendisse cursus lobortis
magna. Vivamus id tortor. Phasellus consectetuer, quam sit amet laoreet
ultrices, tortor leo aliquet turpis." />
</af:panelForm>
<af:panelForm rows="1" maxColumns="1">
<af:inputText label="Lorem ipsum" rows="3" wrap="true"
readOnly="true"
value="Proin orci. Suspendisse cursus lobortis
magna. Vivamus id tortor. Phasellus consectetuer, quam sit amet laoreet
ultrices, tortor leo aliquet turpis." />
<af:inputText label="Lorem ipsum" rows="3" wrap="true"
readOnly="true"
value="Proin orci. Suspendisse cursus lobortis
magna. Vivamus id tortor. Phasellus consectetuer, quam sit amet laoreet
ultrices, tortor leo aliquet turpis." />
<af:inputText label="Lorem ipsum" rows="3" wrap="true"
readOnly="true"
value="Proin orci. Suspendisse cursus lobortis
magna. Vivamus id tortor. Phasellus consectetuer, quam sit amet laoreet
ultrices, tortor leo aliquet turpis." />
</af:panelForm>
<af:panelForm rows="1" maxColumns="1">
<af:inputText label="Lorem ipsum" rows="3" wrap="true"
readOnly="true"
value="Proin orci. Suspendisse cursus lobortis
magna. Vivamus id tortor. Phasellus consectetuer, quam sit amet laoreet
ultrices, tortor leo aliquet turpis." />
<af:inputText label="Lorem ipsum" rows="3" wrap="true"
readOnly="true"
value="Proin orci. Suspendisse cursus lobortis
magna. Vivamus id tortor. Phasellus consectetuer, quam sit amet laoreet
ultrices, tortor leo aliquet turpis." />
<af:inputText label="Lorem ipsum" rows="3" wrap="true"
readOnly="true"
value="Proin orci. Suspendisse cursus lobortis
magna. Vivamus id tortor. Phasellus consectetuer, quam sit amet laoreet
ultrices, tortor leo aliquet turpis." />
</af:panelForm>
</af:panelHorizontal>
</af:panelBox>
I included this in another jspf file
Include-1.jspf
<af:panelBox text="Include-1.jspf includes Include-0.jspf 5 times.">
<jsp:directive.include file="/Include-0.jspf" />
<jsp:directive.include file="/Include-0.jspf" />
<jsp:directive.include file="/Include-0.jspf" />
<jsp:directive.include file="/Include-0.jspf" />
<jsp:directive.include file="/Include-0.jspf" />
</af:panelBox>
I include that in another jspf
Include-2.jspf
<af:panelBox text="Include-2.jspf includes Include-1.jspf 5 times.">
<jsp:directive.include file="/Include-1.jspf" />
<jsp:directive.include file="/Include-1.jspf" />
<jsp:directive.include file="/Include-1.jspf" />
<jsp:directive.include file="/Include-1.jspf" />
<jsp:directive.include file="/Include-1.jspf" />
</af:panelBox>
And that is referenced by my jspx page.
TooManyComponents.jspx
<?xml version='1.0' encoding='windows-1252'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="1.2"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:af="http://xmlns.oracle.com/adf/faces"
xmlns:afh="http://xmlns.oracle.com/adf/faces/html">
<jsp:text>
<![CDATA[ ><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> ]]>
</jsp:text>
<jsp:directive.page contentType="text/html;charset=windows-1252"/>
<f:view>
<afh:script source="/jscript/view_tools.js"/>
<af:document rendered="false">
<af:form id="notloggedin">
<af:panelPage title="This never happens but it mirrors my
problem layour">
<jsp:directive.include file="header.jspf"/>
<af:commandMenuItem text="You are not logged in. Please click
this message to be re-directed to the Login Page" action="login"/>
</af:panelPage>
</af:form>
</af:document>
<af:document rendered="true">
<af:form id="loggedin">
<af:panelPage title="Too much of a good thing?">
<jsp:directive.include file="/header.jspf"/>
<jsp:directive.include file="/Include-2.jspf" />
</af:panelPage>
</af:form>
</af:document>
</f:view>
</jsp:root>
This particular setup yeilded me the following error
Fatal error: Cannot find class java/lang/StackOverflowErrorProcess
exited.Debugger disconnected from local process.
If I put a second
<jsp:directive.include file="/Include-2.jspf" />
in my jspx file I get the following compile time error.
Error: code segment of method
_jspService(javax.servlet.http.HttpServletRequest,
javax.servlet.http.HttpServletResponse) too large
If I remove one of the jsp:include directives from my Include-1.jspf so
that it reads as follows:
<af:panelBox text="Include-1.jspf includes Include-0.jspf 4 times.">
<jsp:directive.include file="/Include-0.jspf" />
<jsp:directive.include file="/Include-0.jspf" />
<jsp:directive.include file="/Include-0.jspf" />
<jsp:directive.include file="/Include-0.jspf" />
</af:panelBox>
The application works.
I took all the JDeveloperStudio defaults for creating my project.
Re: MyFaces support for Facelets
Posted by Adam Winer <aw...@gmail.com>.
Andrew,
I don't see any changes coming in the tag handler API or XML format,
and just asked Jacob, who agrees.
-- Adam
On 5/15/06, Andrew Robinson <an...@gmail.com> wrote:
> What if there is a need for a different JAR for different facelets versions?
> For example, if Jacob changed the tag handler API in Facelets 1.2, then the
> code would be different for Facelets 1.1 and 1.2. This is the big reason I
> see for having the Jars separate.
>
> -Andrew
>
>
> On 5/15/06, Sean Schofield <se...@gmail.com> wrote:
> > > I don't see these as significant advantages to making it a separate
> > > JAR. None of these should be marked as required dependencies for
> > > standard tomahawk use - they should all be marked as "provided"
> > > scope, which avoids the issue.
> >
> > I agreee. Why not include the facelets config file in the META-INF of
> > the regular old tomahawk.jar? It certainly doesn't hurt anyone not
> > using facelets and it would be a major incentive to use MyFaces
> > components if they were able to be used with facelets out of the box.
> >
> > > -- Adam
> >
> > Sean
> >
>
>
Re: MyFaces support for Facelets
Posted by Andrew Robinson <an...@gmail.com>.
What if there is a need for a different JAR for different facelets versions?
For example, if Jacob changed the tag handler API in Facelets 1.2, then the
code would be different for Facelets 1.1 and 1.2. This is the big reason I
see for having the Jars separate.
-Andrew
On 5/15/06, Sean Schofield <se...@gmail.com> wrote:
>
> > I don't see these as significant advantages to making it a separate
> > JAR. None of these should be marked as required dependencies for
> > standard tomahawk use - they should all be marked as "provided"
> > scope, which avoids the issue.
>
> I agreee. Why not include the facelets config file in the META-INF of
> the regular old tomahawk.jar? It certainly doesn't hurt anyone not
> using facelets and it would be a major incentive to use MyFaces
> components if they were able to be used with facelets out of the box.
>
> > -- Adam
>
> Sean
>
Re: MyFaces support for Facelets
Posted by Sean Schofield <se...@gmail.com>.
> I don't see these as significant advantages to making it a separate
> JAR. None of these should be marked as required dependencies for
> standard tomahawk use - they should all be marked as "provided"
> scope, which avoids the issue.
I agreee. Why not include the facelets config file in the META-INF of
the regular old tomahawk.jar? It certainly doesn't hurt anyone not
using facelets and it would be a major incentive to use MyFaces
components if they were able to be used with facelets out of the box.
> -- Adam
Sean
Re: MyFaces support for Facelets
Posted by Adam Winer <aw...@gmail.com>.
On 5/10/06, Mike Kienenberger <mk...@gmail.com> wrote:
> On 5/10/06, Adam Winer <aw...@gmail.com> wrote:
> > > I think we'll want to make it a separate jar and project because
> > > facelets depends on JSF 1.2 RI and the Glassfish EL jars. And maybe
> > > JSP 2.1 as well. Those don't need to be dependencies for standard
> > > tomahawk use.
> >
> > FYI, it doesn't depend on the JSF 1.2 RI, and it *definitely*
> > doesn't depend on JSP 2.1 (or anything in JSP, for that matter).
> > It does require a javax.el implementation; I don't remember offhand
> > if it's hardcoded against the Glassfish implementation or if
> > that's pluggable.
>
> Adam,
>
> When I was working on custom components for the Optional Validation
> Framework, I had issues with dependencies on
> javax.servlet.jsp.tagext.Tag. I went back and reviewed the project,
> but I couldn't duplicate the issue -- I'm probably misremembering the
> root cause and was due to JSP tags instead.
>
> However, com.sun.facelets.tag.jsf.ComponentHandler references
> javax.faces.component.ActionSource2 (a dependencies on the JSF 1.2
> api). I thought for sure that this was causing a compile-time
> dependency, but again I can't repeat the problem.
I should clarify: there's definitely a compile-time dependency
on JSF 1.2. But I got Jacob to make it so that it's compile-time
only, and there's no runtime dependency.
-- Adam
> In that case, I'd prefer option 1!
>
Re: MyFaces support for Facelets
Posted by Mike Kienenberger <mk...@gmail.com>.
On 5/10/06, Adam Winer <aw...@gmail.com> wrote:
> > I think we'll want to make it a separate jar and project because
> > facelets depends on JSF 1.2 RI and the Glassfish EL jars. And maybe
> > JSP 2.1 as well. Those don't need to be dependencies for standard
> > tomahawk use.
>
> FYI, it doesn't depend on the JSF 1.2 RI, and it *definitely*
> doesn't depend on JSP 2.1 (or anything in JSP, for that matter).
> It does require a javax.el implementation; I don't remember offhand
> if it's hardcoded against the Glassfish implementation or if
> that's pluggable.
Adam,
When I was working on custom components for the Optional Validation
Framework, I had issues with dependencies on
javax.servlet.jsp.tagext.Tag. I went back and reviewed the project,
but I couldn't duplicate the issue -- I'm probably misremembering the
root cause and was due to JSP tags instead.
However, com.sun.facelets.tag.jsf.ComponentHandler references
javax.faces.component.ActionSource2 (a dependencies on the JSF 1.2
api). I thought for sure that this was causing a compile-time
dependency, but again I can't repeat the problem.
In that case, I'd prefer option 1!
Re: MyFaces support for Facelets
Posted by Adam Winer <aw...@gmail.com>.
On 5/9/06, Mike Kienenberger <mk...@gmail.com> wrote:
> Thomas and I have talked on and off about adding facelets support
> natively to MyFaces Tomahawk.
>
> http://issues.apache.org/jira/browse/TOMAHAWK-79
>
> Things that were holding us up in the past were no code generator.
> That's now available again, although I haven't had time to look into
> using it.
>
> Also, we're waiting for a maven-repository version of facelets to
> appear. That should happen shortly as ADFFaces also needs it.
I'll have all next week to beat on Jacob. :)
> I think we'll want to make it a separate jar and project because
> facelets depends on JSF 1.2 RI and the Glassfish EL jars. And maybe
> JSP 2.1 as well. Those don't need to be dependencies for standard
> tomahawk use.
FYI, it doesn't depend on the JSF 1.2 RI, and it *definitely*
doesn't depend on JSP 2.1 (or anything in JSP, for that matter).
It does require a javax.el implementation; I don't remember offhand
if it's hardcoded against the Glassfish implementation or if
that's pluggable.
I don't see these as significant advantages to making it a separate
JAR. None of these should be marked as required dependencies for
standard tomahawk use - they should all be marked as "provided"
scope, which avoids the issue.
-- Adam
> As for things like tree2, the best solution is to fix them in Tomahawk
> rather than add a workaround for facelets. That allows other
> alternate view handlers to work as well. Sean checked in a tree2 fix
> this week. We still need one for extended data table.
>
> -Mike
>
> On 5/9/06, Andrew Robinson <an...@gmail.com> wrote:
> > Until now, most people are using the WIKI[1] for getting myfaces to
> > work with facelets. I was wondering if we want to make MyFaces include
> > support for facelets natively. This should be able to be done in such
> > a way to prevent problems for those that do not use facelets.
> >
> > Option 1)
> > Add everything to tomahawk.jar including the TagHandler classes and
> > taglib.xml file(s).
> >
> > This is easiest, and will not cause issues since non-facelet users
> > will not be using those classes, and therefore if they don't have
> > facelets in their classpath, it shouldn't matter.
> >
> > Option 2)
> > Create a new myfaces jar file (tomahawk-facelets-1.1.2.jar for
> > example) that contains only the code and configuration necessary to
> > "plug" tomahawk into facelets.
> >
> > This is possibly more elegant but more of a pain to setup.
> >
> > Option 3)
> > Maintain all this at jsf-comp.
> >
> > This works, but new users may not know about jsf-comp and it is harder
> > to stay in sync with facelet and myfaces version changes (since it is
> > not tied into the release cycle).
> >
> > Since facelets hasn't changed the taglib.xml structure at all, facelet
> > version should not be a major issue. This would also make issues like
> > what tree2 had a mute point since we could include component handlers
> > built in to translate any "non-standard" logic in the Tag classes.
> >
> > This methodology could be applied to the sandbox as well. Once there
> > is some code in SVN I would think myfaces developers could easily
> > maintain their configuration for their components as well since there
> > would be examples from other components to learn from (so even
> > developers without facelets experience shouldn't have any issues).
> >
> > What do you think?
> > -Andrew
> >
> > [1] http://wiki.apache.org/myfaces/Use_Facelets_with_Tomahawk
> >
>
Re: MyFaces support for Facelets
Posted by Mike Kienenberger <mk...@gmail.com>.
Thomas and I have talked on and off about adding facelets support
natively to MyFaces Tomahawk.
http://issues.apache.org/jira/browse/TOMAHAWK-79
Things that were holding us up in the past were no code generator.
That's now available again, although I haven't had time to look into
using it.
Also, we're waiting for a maven-repository version of facelets to
appear. That should happen shortly as ADFFaces also needs it.
I think we'll want to make it a separate jar and project because
facelets depends on JSF 1.2 RI and the Glassfish EL jars. And maybe
JSP 2.1 as well. Those don't need to be dependencies for standard
tomahawk use.
As for things like tree2, the best solution is to fix them in Tomahawk
rather than add a workaround for facelets. That allows other
alternate view handlers to work as well. Sean checked in a tree2 fix
this week. We still need one for extended data table.
-Mike
On 5/9/06, Andrew Robinson <an...@gmail.com> wrote:
> Until now, most people are using the WIKI[1] for getting myfaces to
> work with facelets. I was wondering if we want to make MyFaces include
> support for facelets natively. This should be able to be done in such
> a way to prevent problems for those that do not use facelets.
>
> Option 1)
> Add everything to tomahawk.jar including the TagHandler classes and
> taglib.xml file(s).
>
> This is easiest, and will not cause issues since non-facelet users
> will not be using those classes, and therefore if they don't have
> facelets in their classpath, it shouldn't matter.
>
> Option 2)
> Create a new myfaces jar file (tomahawk-facelets-1.1.2.jar for
> example) that contains only the code and configuration necessary to
> "plug" tomahawk into facelets.
>
> This is possibly more elegant but more of a pain to setup.
>
> Option 3)
> Maintain all this at jsf-comp.
>
> This works, but new users may not know about jsf-comp and it is harder
> to stay in sync with facelet and myfaces version changes (since it is
> not tied into the release cycle).
>
> Since facelets hasn't changed the taglib.xml structure at all, facelet
> version should not be a major issue. This would also make issues like
> what tree2 had a mute point since we could include component handlers
> built in to translate any "non-standard" logic in the Tag classes.
>
> This methodology could be applied to the sandbox as well. Once there
> is some code in SVN I would think myfaces developers could easily
> maintain their configuration for their components as well since there
> would be examples from other components to learn from (so even
> developers without facelets experience shouldn't have any issues).
>
> What do you think?
> -Andrew
>
> [1] http://wiki.apache.org/myfaces/Use_Facelets_with_Tomahawk
>
Re: MyFaces support for Facelets
Posted by Andrew Robinson <an...@gmail.com>.
I forgot one point, option (2) has one benefit over option (1): there could
be separate jar files for different facelets versions if at anytime facelets
broke compatibility.
-Andrew
On 5/9/06, Adam Brod <AB...@intralinks.com> wrote:
>
>
> I vote for option 1. A couple small files/classes won't add much to the
> jar size and it will greatly improve the experience for somebody just trying
> to get up and running.
>
> Great idea.
> *
> Adam Brod**
> Product Development Team*
>
> *"Andrew Robinson" <an...@gmail.com>*
>
> 05/09/2006 04:05 PM Please respond to
> "MyFaces Discussion" <us...@myfaces.apache.org>
>
> To
> "MyFaces Discussion" <us...@myfaces.apache.org> cc
>
> Subject
> MyFaces support for Facelets
>
>
>
>
>
>
> Until now, most people are using the WIKI[1] for getting myfaces to
> work with facelets. I was wondering if we want to make MyFaces include
> support for facelets natively. This should be able to be done in such
> a way to prevent problems for those that do not use facelets.
>
> Option 1)
> Add everything to tomahawk.jar including the TagHandler classes and
> taglib.xml file(s).
>
> This is easiest, and will not cause issues since non-facelet users
> will not be using those classes, and therefore if they don't have
> facelets in their classpath, it shouldn't matter.
>
> Option 2)
> Create a new myfaces jar file (tomahawk-facelets-1.1.2.jar for
> example) that contains only the code and configuration necessary to
> "plug" tomahawk into facelets.
>
> This is possibly more elegant but more of a pain to setup.
>
> Option 3)
> Maintain all this at jsf-comp.
>
> This works, but new users may not know about jsf-comp and it is harder
> to stay in sync with facelet and myfaces version changes (since it is
> not tied into the release cycle).
>
> Since facelets hasn't changed the taglib.xml structure at all, facelet
> version should not be a major issue. This would also make issues like
> what tree2 had a mute point since we could include component handlers
> built in to translate any "non-standard" logic in the Tag classes.
>
> This methodology could be applied to the sandbox as well. Once there
> is some code in SVN I would think myfaces developers could easily
> maintain their configuration for their components as well since there
> would be examples from other components to learn from (so even
> developers without facelets experience shouldn't have any issues).
>
> What do you think?
> -Andrew
>
> [1] http://wiki.apache.org/myfaces/Use_Facelets_with_Tomahawk
>
> Disclaimer: This electronic mail and any attachments are confidential and may be privileged. If you are not the intended recipient, please notify the sender immediately by replying to this email, and destroy all copies of this email and any attachments. Thank you.
>
>
Re: MyFaces support for Facelets
Posted by Adam Brod <AB...@intralinks.com>.
I vote for option 1. A couple small files/classes won't add much to the
jar size and it will greatly improve the experience for somebody just
trying to get up and running.
Great idea.
Adam Brod
Product Development Team
"Andrew Robinson" <an...@gmail.com>
05/09/2006 04:05 PM
Please respond to
"MyFaces Discussion" <us...@myfaces.apache.org>
To
"MyFaces Discussion" <us...@myfaces.apache.org>
cc
Subject
MyFaces support for Facelets
Until now, most people are using the WIKI[1] for getting myfaces to
work with facelets. I was wondering if we want to make MyFaces include
support for facelets natively. This should be able to be done in such
a way to prevent problems for those that do not use facelets.
Option 1)
Add everything to tomahawk.jar including the TagHandler classes and
taglib.xml file(s).
This is easiest, and will not cause issues since non-facelet users
will not be using those classes, and therefore if they don't have
facelets in their classpath, it shouldn't matter.
Option 2)
Create a new myfaces jar file (tomahawk-facelets-1.1.2.jar for
example) that contains only the code and configuration necessary to
"plug" tomahawk into facelets.
This is possibly more elegant but more of a pain to setup.
Option 3)
Maintain all this at jsf-comp.
This works, but new users may not know about jsf-comp and it is harder
to stay in sync with facelet and myfaces version changes (since it is
not tied into the release cycle).
Since facelets hasn't changed the taglib.xml structure at all, facelet
version should not be a major issue. This would also make issues like
what tree2 had a mute point since we could include component handlers
built in to translate any "non-standard" logic in the Tag classes.
This methodology could be applied to the sandbox as well. Once there
is some code in SVN I would think myfaces developers could easily
maintain their configuration for their components as well since there
would be examples from other components to learn from (so even
developers without facelets experience shouldn't have any issues).
What do you think?
-Andrew
[1] http://wiki.apache.org/myfaces/Use_Facelets_with_Tomahawk
Disclaimer: This electronic mail and any attachments are confidential and may be privileged. If you are not the intended recipient, please notify the sender immediately by replying to this email, and destroy all copies of this email and any attachments. Thank you.