Re: problem getting 1.1.1 from svn
Even with that suggested URL, svn co http://svn.apache.org/repos/asf/myfaces/legacy/tags/before_maven_reorg/release/tags/1_1_1/ I get the same error: Fetching external item into '1_1_1\share' svn: URL 'https://svn.apache.org/repos/asf/myfaces/share/tags/1_1_1' doesn't exist I'm not familiar with the term externals. I've always been confused by the way the MyFaces SVN repository works (how you can't see the files if you view http://svn.apache.org/repos/asf/myfaces/legacy/tags/before_maven_reorg/release/tags/1_1_1/ in a web browser) but you can use that URL to check out files). Anyway, I'll hold off for now until you have a chance to sort things out after restructuring for Maven. I'm very much looking forward to the new Maven 2 build... On 1/4/06, Sean Schofield [EMAIL PROTECTED] wrote: This is because we renamed the share project to commons.Even thougheverything is preserved in the legacy folder[1] there are apparentlysome effects we hadn't anticipated.For now you should be able to getit using the legacy/release folder[2]. This is actually a pretty big mess to clean up.Maybe we can fix thisby creating externals for the release tags.I'm still not sure whatto do about all of the other externals for the other tags and branches ...Sean[1] http://svn.apache.org/repos/asf/myfaces/legacy/tags/before_maven_reorg/[2] http://svn.apache.org/repos/asf/myfaces/legacy/tags/before_maven_reorg/release/tags/1_1_1/
problem getting 1.1.1 from svn
I tried to checkout the MyFaces source tree from SVN using this command: svn co https://svn.apache.org/repos/asf/myfaces/release/tags/1_1_1/ It was able to get the api and impl subfolders, but when it got to share, I got this error: Fetching external item into '1_1_1\share' svn: URL 'https://svn.apache.org/repos/asf/myfaces/share/tags/1_1_1' doesn't exist Am I using the right technique to obtain the MyFaces 1.1.1 sources from SVN? -Ken
Re: how can i arrange the style in the t:selectChecManyBox
Could you draw an example of the arrangement of the checkboxes that you're trying to produce?On 12/19/05, Lee YanSong
[EMAIL PROTECTED] wrote:Hi all
now i use t:selectManyCheckbox to display a list of checkbox, but the style displayed is
not my wanted. if i want to arrangethewidthevery column, how did i do ?
this is my code, butthe
t:selectManyCheckbox style=width:100% layout=lineDirection layoutWidth=2
f:selectItems
value=#{createRulePage.targetingFields}/
/t:selectManyCheckbox
Re: MyFaces Cherokee
Hi Matthias, Does the book have some good examples of building components that are based on child components, e.g. a PhoneNumber component with 3 InputText child components? -KenOn 12/16/05, Matthias Wessendorf [EMAIL PROTECTED] wrote: PS: The book is cool, I have read it already ;)On 12/16/05, Nicklas Karlsson [EMAIL PROTECTED] wrote: February 2006 - book release: Pro JSF by Jonas Jacobi and John Fallows (Apress); targeted at JSF Component developers
Re: Prevent Firefox from caching..
We use something similar which seems to work fine on Firefox and IE: res:setHeader name=Pragmano Cache/res:setHeader res:setHeader name=Cache-controlno-store,no-cache/res:setHeader res:setDateHeader name=Expire0/res:setDateHeader These are taglibs from http://jakarta.apache.org/taglibs/On 11/10/05, Mario Ivankovits [EMAIL PROTECTED] wrote:[EMAIL PROTECTED] wrote: Does anyone know, how to tell Firefox not to cache pages... I have implemented a Chart via Jenia and the problem is that, when the page is display, the chart from the previous request is shown, until I press F5We useresponse.setHeader(Cache-Control, no-store);response.setHeader(Pragma, no-cache);And this works.---Mario
Re: ApplicationImpl Configuration Problem
Thanks for the reply, Martin.
I'm not really sure if I understand whether or not they are MyFaces
specific or not. Some seem to be standard as they have
javax.faces in their ID's and come from a file called
standard-faces.config.xml.
These are the converter ID's for which FacesConfigurator tries to set the Converter configuration instance:
javax.faces.convert.BooleanConverter
javax.faces.convert.NumberConverter
javax.faces.convert.BigIntegerConverter
javax.faces.convert.DoubleConverter
org.lmb.faces.converter.bool.BooleanConverter
javax.faces.convert.FloatConverter
javax.faces.convert.IntegerConverter
javax.faces.convert.ByteConverter
org.apache.myfaces.convert.StringArrayConverter
org.apache.myfaces.custom.fileupload.UploadedFileConverter
javax.faces.convert.BigDecimalConverter
javax.faces.convert.ShortConverter
javax.faces.convert.CharacterConverter
javax.faces.convert.LongConverter
javax.faces.convert.DateTimeConverter
Since my Application is not an ApplicationImpl, then FacesConfigurator
doesn't inject the configuration into ApplicationImpl and then when
MyApplication delegates to ApplicationImpl, ApplicationImpl throws a
NullPointerException in this code because it has a registered converter
but not the corresponding configuration:
private Converter internalCreateConverter(Class targetClass) {
Converter converter = (Converter) converterClass.newInstance();
org.apache.myfaces.config.impl.digester.elements.Converter
converterConfig =
(org.apache.myfaces.config.impl.digester.elements.Converter)
_converterClassNameToConfigurationMap.get(converterClass.getName());
Iterator it = converterConfig.getProperties(); -- a NPE is thrown
here because converterConfig is null
}
The result is this stack trace. My application is SpringApplication:
Caused by: javax.faces.FacesException: Could not instantiate converter: class javax.faces.convert.IntegerConverter
at org.apache.myfaces.application.ApplicationImpl.internalCreateConverter(ApplicationImpl.java:556)
at org.apache.myfaces.application.ApplicationImpl.createConverter(ApplicationImpl.java:494)
at org.lmb.web.jsf.SpringApplication.createConverter(SpringApplication.java:287)
... 34 more
Caused by: java.lang.NullPointerException
at org.apache.myfaces.application.ApplicationImpl.internalCreateConverter(ApplicationImpl.java:534)
... 36 more
Does this make sense? Is this a problem, or am I doing something wrong
by writing my own application factory and application and delegating to
the original?
-Ken
On 11/9/05, Martin Marinschek [EMAIL PROTECTED] wrote:
But this is just additional, MyFaces specific configuration, right?The converters get added alright, they are just not processingadditional stuff in the faces-config file that would be special toMyFaces?
regards,MartinOn 11/9/05, Ken Weiner [EMAIL PROTECTED] wrote: I have a custom ApplicationFactory that wraps the original ApplicationFactory so that it can produce a custom Application that wraps
the original Application.It is configured via faces-config.xml:factoryapplication-factorycustom.MyApplicationFactory/application-factory/factory
As a result, the FacesConfigurator class is not able to properly configure all the standard Converters (for Integer, Long, etc) because it relies on setting instances of org.apache.myfaces.config.impl.digester.elements.Converter
on the ApplicationImpl (and my Application is not an instance of ApplicationImpl):if(application instanceof ApplicationImpl){for (Iterator it = _dispenser.getConverterConfigurationByClassName();
it.hasNext();){String converterClassName = (String) it.next();((ApplicationImpl) application).addConverterConfiguration(converterClassName,
_dispenser.getConverterConfiguration(converterClassName));}}Therefore this inner block of code is passed over in my environment.Is there any way that MyFaces can be changed so that ApplicationImpl does not
need to know about org.apache.myfaces.config.impl.digester.elements.Converter internally?It would be nice if the FacesConfigurator could configure any Application without relying on it being an ApplicationImpl.
--http://www.irian.atYour JSF powerhouse -JSF Consulting, Development andCourses in English and GermanProfessional Support for Apache MyFaces
Re: Boolean converter?
Yes, the issue in JIRA was http://issues.apache.org/jira/browse/MYFACES-451 You can get the source code from the MyFaces sandbox.On 9/14/05, Dennis Byrne [EMAIL PROTECTED] wrote: I think he put it in JIRA. Original message Date: Wed, 14 Sep 2005 18:00:05 -0500 From: CONNER, BRENDAN \(SBCSI\) [EMAIL PROTECTED]Subject: Boolean converter?To: MyFaces Discussion users@myfaces.apache.orgI recall from one of the earlier postings that someone haddeveloped aboolean converter.Is that available?- BrendanDennis Byrne
setting headers on the response in JSF
What is the best way to set headers on the HttpResponse to control things such as caching directives? For example: response.setHeader(Cache-Control, no-cache); Would I need to implement a PhaseListener? Is this done through config parameters of some kind? Should I just include a scriptlet in each JSP page? -Ken
Re: changing the rendering behavior of HtmlSelectManyCheckbox
Thanks. Does your columns attribute work with page direction and
line direction? I ended up extending the component as well to
handle a width of checkboxes in both directions. I'll take a
look at your code next week to see if it is similar and if I can
enhance it with both drawing directions if it isn't already done.On 9/7/05, Jan Bols [EMAIL PROTECTED] wrote:
I had the same problem and ended up extending the HtmlSelectManyCheckboxcomponent. I added a columns attribute where you can specify the number
of columns you want the selectManyCheckbox to use. Like this:cc:selectManyCheckboxlayout=pageDirectioncolumns=2
f:selectItems
value=#{mySelectItems}//cc:selectManyCheckboxYou can find the sourcecode on http://sourceforge.net/projects/jsf-comp
but there's also a jar that you can add to WEB-INF/lib directory. The jarfile is found on http://www.ivpv.ugent.be/~jan/myfacessandbox.jar. The jar
file is for use with the nightly version (so not the 1.0.9 version) ofmyfaces dating from 2005-08-15 but with a bit of luck it should also workwith the current nightly version of myfaces.You can find a working example of this on
https://www.ivpv.ugent.be/contact/new.faces?lang=en . Also onhttp://www.ivpv.ugent.be/~jan/selectTest.jsp
you can find a jsf file toget you started...Hope this helps.JanOn Thu, 01 Sep 2005 22:19:36 +0200, Ken Weiner [EMAIL PROTECTED] wrote:
I need to find a way to render the checkboxes in HtmlSelectManyCheckbox in a format other than a single horizontal or vertical row. My first thought was to extend HtmlSelectManyCheckbox and make a new attribute called width
and use this in conjunction with the layout attribute as follows: h:selectManyCheckbox value=#{backingBean.someArray} layout=pageDirection width=3
f:selectItems value=#{backingBean.someSelectItems}/ /h:selectManyCheckbox would produce [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x]
[x] [x] [x] [x] [x] [x] etc. and h:selectManyCheckbox value=#{backingBean.someArray} layout=lineDirection width=3
f:selectItems value=#{backingBean.someSelectItems}/ /h:selectManyCheckbox would produce [x] [x] [x] [x] [x] [x] etc. [x] [x] [x] [x] [x] [x]
[x] [x] [x] [x] [x] [x] Is there better way to accomplish this? Should I be thinking about using SelectItemGroups? I'm ultimately trying to create a 2 X 2 set of checkboxes. Thanks!
-Ken
Re: JSF + Spring + Hibernate
I have a question about designing a webapp to use a DAO layer, lazily loaded objects, Hibernate, and the OpenSessionInView technique. Doesn't this strategy make it very difficult to reimplement the DAO layer sometime in the future? If you switched a DAO implementation from Hibernate to let's say, Spring JDBC, then how would all the lazy loading work? There would be no equivalent OpenSessionInView technique for Spring JDBC. For this reason, I have been shying away from designing my domain objects such that the rest of the app expects them to lazily load data. So, instead of a Company class having a getEmployees() method, I would choose, instead, to have a CompanyDao.getEmployees(Company company) method that must be called at the point my webapp needs all the Employees for a Company. Have any of you had the same concerns? Or am I missing how a webapp that relies on lazy-loaded object graphs can change DAO implementations easily? -Ken
Re: JSF + Spring + Hibernate
The issue I was getting at was that knowing that your app has this lazy loading capability, you may make different design decisions on what methods go into your domain objects and what your domain object graph looks like. I prefer to design the domain object graphs, keeping in mind that the DAO layer would be responsible for completely loading the graphs. So if there are many Employees for a Company and you don't always want to load the Employees when you load a Company, then I probably wouldn't put a getEmployees() method on the Company class. I guess you could argue that it is okay to add the getEmployees() method and document it so that sometimes it returns null and sometimes it doesn't, but that seems undesireable to me. I'd rather leave off the method and add an extra method to a DAO that can fetch the employees for a Company whenever I need them. -KenOn 8/31/05, Werner Punz [EMAIL PROTECTED] wrote: well OpenSessionInView... is one of those rare circumstances where itactually makes sense, because it eases the portability and implementation...I would not say it reall is dependend on the view layer, more on the control layer of the server...It is one of those border cases...Larry Meadors wrote: Heheh, are you suggesting that making your DAO layer depend upon your view layer is a bad idea? I would have to agree Larry On 8/31/05, Ken Weiner [EMAIL PROTECTED] wrote:I have a question about designing a webapp to use a DAO layer, lazily loaded objects, Hibernate, and the OpenSessionInView technique. Doesn't this strategy make it very difficult to reimplement the DAO layersometime in the future?If you switched a DAO implementation from Hibernate to let's say, Spring JDBC, then how would all the lazy loading work?Therewould be no equivalent OpenSessionInView technique for Spring JDBC.Forthis reason, I have been shying away from designing my domain objects such that the rest of the app expects them to lazily load data. So, instead of a Company class having a getEmployees() method, I wouldchoose, instead, to have a CompanyDao.getEmployees (Company company) methodthat must be called at the point my webapp needs all the Employees for aCompany. Have any of you had the same concerns?Or am I missing how a webapp that relies on lazy-loaded object graphs can change DAO implementations easily? -Ken
Re: best way to initialize BackingBean?
I hadn't thought of that. I guess it would work fine when you
want to specify a converter by ID. However, it wouldn't work when
JSF looks for a converter by Class, would it?On 8/31/05, Craig McClanahan [EMAIL PROTECTED] wrote:
On 8/31/05, Ken Weiner
[EMAIL PROTECTED] wrote:
The Spring JSF integration I've seen focuses on enabling Spring IoC for
JSF managed beans. There is a way to enable IoC for JSF
Converters, Validators, and UIComponents too. I posted
information on the Spring JSF Wiki: http://opensource.atlassian.com/confluence/spring/x/Qgo
I was hoping Spring would incorporate the SpringApplication and
SpringApplicationFactory code in a future release, but there haven't
yet been comments on the Wiki page.
For converters, isn't this already possible out of the box (if you've got the Spring IoC integration with managed beans)?
h:inputText ... converter=#{myConverter} .../
where myConverter is a spring bean.
For validators, you can bind to a validator *method* of some bean that happens to be created via the IoC facility.
-Ken
Craig
Re: Errors
I think you need to make sure servlet.jar is in your classpath.On 8/29/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:Hello!I try to implement my own custom compontent. But I get one Error in my Tag.javaand one Error for the project.The type javax.servlet.jsp.tagext.Tag cannot be resolved. It is indirectly referenced from required .class filesThe project was not built since its build path is incomplete. Cannot find the class file for javax.servlet.jsp.tagext.Tag. Fix the build path then try building this projectWhats the problem?Thanks shed--Ein Service von http://www.sms.at
Re: x:convertBoolean
Thanks Sean. I just created http://issues.apache.org/jira/browse/MYFACES-451 and uploaded my code and patches in case anyone wants to take a look. I'm happy to add more docs and unit tests if required. On 8/25/05, Sean Schofield [EMAIL PROTECTED] wrote: Looking forward to your contribution. Dennis is correct in pointing out that the patch should be for sandbox. Feel free to ask around on the dev list if you have questions regarding procedure, patching, etc. sean
Re: How to call a method in the backing bean from a JSF page
I am not sure if this is the best way, but one idea that could work is
to create a PhaseListener that acts after the view is restored. In
this phase listener, you could check if the view being restored is the
view for which you want to call your backing bean method. Then, you
could obtain a MessageBinding object for your backing bean expression
and use that to call your method.
Create YourPhaseListener and register it in faces-config.xml:
faces-config
...
lifecycle
phase-listenercom.yourcompany.YourPhaseListener/phase-listener
/lifecycle
/faces-config
public class YourPhaseListener implements PhaseListener {
public void beforePhase(PhaseEvent event) {
// Nothing to do
}
public void afterPhase(PhaseEvent event) {
FacesContext facesContext = event.getFacesContext();
UIViewRoot viewRoot = facesContext.getViewRoot();
String idOfYourPage = ...
if (viewRoot.getId().equals(idOfYourPage)) {
Application application = facesContext.getApplication();
String methodExpression = ...
Class[] params = ...
MethodBinding methodBinding =
application.getMessageBinding(methodExpression, params);
methodBinding.invoke(facesContext, ...);
}
public PhaseId getPhaseId() {
return PhaseId.RESTORE_VIEW;
}
}
Disclaimer: I haven't tried this code so I don't know if it would work
or even compile.
-Ken
On 8/24/05, Saul Qunming Yuan [EMAIL PROTECTED] wrote:
Thanks for your response. I guess I didn't make me clear here. My question
is how to call a method in the backing bean from a JSF page without
rendering out anything to the screen.
x:convertBoolean
JSF has f:convertDateTime and f:convertNumber, but nothing I've
seen to convert Booleans to custom values. Has something like
x:convertBoolean already been written by anyone? I have just
written one and would be willing to contribute it to MyFaces if there
is interest.
It is used like this:
h:outputText value=#{backingBean.isABooleanValue}
x:convertBoolean trueValue=Yes falseValue=No/
/h:outputText
-Ken
Re: x:convertBoolean
Ok, great, I will get familiar with the sandbox, change my code to follow the packages for tomahawk, and submit patches to JIRA. Looking forward to participating... On 8/25/05, Sean Schofield [EMAIL PROTECTED] wrote: Suggestion: Add an issue to JIRA (select sandbox as the component type.) This gives committers a chance to shout down any ideas they find completely objectionable so you don't waste your time (this is not one of those ideas btw.) Then provide a SVN patch and we'll add it to sandbox. Be prepared to provide documentation and a simple example (or add to an existing simple example) when appropriate. The docs and examples are now required for new tomahawk goodies. sean On 8/25/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Looks convenient Ken. Please post your code. I would like to see it, even if this does not make it to the issue tracker. Dennis Byrne
Re: Why not reuse jsf-api.jar from Sun?
Martin, yes, I will file this as an issue in Jira and reference this
email thread.
Craig, thank you so much for your response. I now understand the
relationship between a java spec and the physical API source code much
better. You brought up an interesting point about JSF being different
in that there is more executable code than in other frameworks. What
was the reason that classes like javax.faces.render.Renderer were
defined as abstract classes rather than interfaces? In Section 8.2,
the spec refers to what an instance of Renderer should do. Does the
word instance imply a class rather than interface or is it up to the
implementation?
-Ken
On 8/24/05, Martin Marinschek [EMAIL PROTECTED] wrote:
Ken,
can I ask you to file that as a jira-issue?
If possible, include both yours and Craigs evaluation of the problem
as comments.
regards,
Martin
On 8/24/05, Craig McClanahan [EMAIL PROTECTED] wrote:
On 8/23/05, Ken Weiner [EMAIL PROTECTED] wrote:
Thanks for the replies. Do other specs from JCP behave this way?
Yes, they *all* do. An implementation of a JCP spec is required to
provide the javax.foo classes, as well as whatever implementation
classes they require to conform to the spec requirements. The primary
difference for JSF is there is relatively more executable code in the
javax.faces classes, rather than just specifying APIs. But the
compatibility test that MyFaces will be required to pass include
signature tests that ensure any given implementation implements
*exactly* the set of public and protected methods (and variables if
any) as is required by the spec.
don't remember ever seeing another situation where there are multiple
versions of the same exact (same fully-qualified name) class.
Question -- where do you get your definition of javax.servlet.Servlet
when you compile your webapp? Answer ... that is totally up to the
server implementation you are using -- they do *not* all necessarily
share the same physical source code (although such sharing is not
uncommon either -- lots of app server vendors use the same
javax.servlet classes that Tomcat does, for example, because they are
available under the Apache license).
The same principle applies to all of the JCP specs.
Here is an example of how my component would break if I switched
implementations:
Let's say I am coding a component that has children components. My
component extends javax.faces.render.Renderer. If I am using the RI,
I may be tempted to accept (not override) the implementation of
Renderer.encodeChildren() which simply iterates thought the children
and renders them as follows:
public void encodeChildren(FacesContext context, UIComponent
component)
throws IOException {
if (context == null || component == null) {
throw new NullPointerException();
}
Iterator kids = component.getChildren().iterator();
while (kids.hasNext()) {
UIComponent kid = (UIComponent) kids.next();
kid.encodeBegin(context);
if (kid.getRendersChildren()) {
kid.encodeChildren(context);
}
kid.encodeEnd(context);
}
}
Now if I switch to MyFaces, none of my children would render because
the MyFaces version of javax.faces.render.Renderer.encodeChildren()
does not render the children. It looks like this:
public void encodeChildren(FacesContext context, UIComponent
component)
throws IOException
{
if (context == null) throw new NullPointerException(context);
if (component == null) throw new
NullPointerException(component);
}
So if I understand things correctly, my component would essentially
break because none of its children would render with MyFaces. Does
that make sense?
There are a couple bunch of overlapping questions here.
* Does the spec require a particular behavior of this method? If so,
then an implementation that doesn't follow those requirements is
totally broken, and should not be used until it is fixed.
* Do the compatibility tests actually test that particular asserion?
This will vary by assertion (like any other piece of software, the
TCK tests are limited by how much resource can be devoted to
creating them), so you cannot expect 100% coverage of even the
testable assertions. But, even if an assertion is not tested,
failure to conform to the requirements means the implementation
is broken (and, to be fair, the MyFaces folks will go out of their way
to ensure compatibility with the spec requirements).
* Does a particular implementation (either the RI or MyFaces in this case)
do something *not* required by the spec? That's also perfectly legal
as long as they don't violate any of the spec requirements
Re: Why not reuse jsf-api.jar from Sun?
Trust me ... you don't want to read all the EG threads on that topic :-). But the short answer is, consider what happens in a future version of JSF, when (for good reason) a new method signature is added to the Renderer API. If it were an interface, you've just broken every current implementation in the world. As an abstract base class, you can add a default implementation that mirrors the previous behavior, so the only potential breakage is if an implementation had their own version of that very same method signature. It seems like you could get the best of both worlds with an interface and an abstract class that implements it. Since this has been well-vetted by the EG, I'll accept the reasons it was done without an interface. An actual instance, of course, must be of a concrete class that can be instantiated. But whether that concrete class extends an abstract base class, or implements an interface, is irrelevant to how many copies there are. In this particular case, it simply has to be that instanceof Renderer returns true, since the JSF implementation is going to cast it to this before calling its methods. So, it sounds like the JSF implementation *does* get to choose whether or not javax.faces.render.Renderer is an abstract class or in interface since an instanceof Renderer check could be done for an instance of either. Am I understanding correctly? Craig
Re: confusion on best practices in regard to a VO in BackingBean
I believe Slawek was referring to Rick Hightower. On 8/24/05, Rick Reumann [EMAIL PROTECTED] wrote: On 8/24/05, Slawek [EMAIL PROTECTED] wrote: but Rick says in his article that: view is only jsp page, controler is backing bean and model has business logic I take it by article you mean 'e-mail post' ? I don't think I posted any comments on JSF architecture since I obviously am just learning it myself. -- Rick
Why not reuse jsf-api.jar from Sun?
I am confused about the nature of the javax.faces sources that are included in the MyFaces jar file. They appear to have been written as part of the MyFaces project. Sun includes alternative versions of the javax.faces classes in its RI distribution, placing those classes in a seperate jar file: jsf-api.jar. Why doesn't MyFaces reuse the jsf-api.jar from Sun? Shouldn't there only be one version of the API classes, with Sun RI, MyFaces, and other supplying only the impl of the API? The way it is now, if I were to write my own, let's say MyAbstractRenderer, and I extend javax.faces.render.Renderer, then my components could break if I switch between the RI and MyFaces. I hope someone can help me understand the nature of the JSF spec, API classes, and various implementations. Thanks. -Ken
Re: Why not reuse jsf-api.jar from Sun?
Thanks for the replies. Do other specs from JCP behave this way? I
don't remember ever seeing another situation where there are multiple
versions of the same exact (same fully-qualified name) class.
Here is an example of how my component would break if I switched
implementations:
Let's say I am coding a component that has children components. My
component extends javax.faces.render.Renderer. If I am using the RI,
I may be tempted to accept (not override) the implementation of
Renderer.encodeChildren() which simply iterates thought the children
and renders them as follows:
public void encodeChildren(FacesContext context, UIComponent component)
throws IOException {
if (context == null || component == null) {
throw new NullPointerException();
}
Iterator kids = component.getChildren().iterator();
while (kids.hasNext()) {
UIComponent kid = (UIComponent) kids.next();
kid.encodeBegin(context);
if (kid.getRendersChildren()) {
kid.encodeChildren(context);
}
kid.encodeEnd(context);
}
}
Now if I switch to MyFaces, none of my children would render because
the MyFaces version of javax.faces.render.Renderer.encodeChildren()
does not render the children. It looks like this:
public void encodeChildren(FacesContext context, UIComponent component)
throws IOException
{
if (context == null) throw new NullPointerException(context);
if (component == null) throw new NullPointerException(component);
}
So if I understand things correctly, my component would essentially
break because none of its children would render with MyFaces. Does
that make sense?
I realize I could override the encodeChildren() method to be safe, but
don't you agree that it would be easy for someone to fall into a trap?
Maybe, in this case, one of the implementations is not adhering to
the spec.
-Ken
On 8/23/05, Sean Schofield [EMAIL PROTECTED] wrote:
The way it is now, if I were to write my own, let's say
MyAbstractRenderer, and I extend javax.faces.render.Renderer, then my
components could break if I switch between the RI and MyFaces. I hope
someone can help me understand the nature of the JSF spec, API
classes, and various implementations. Thanks.
This shouldn't be the case. The JSF spec carefully defines not only
the method signatures but the anticipated effects of these methods.
Both implementations should be interchangeable.
-Ken
sean
