On 7/9/05, Martin Marinschek (JIRA) myfaces-dev@incubator.apache.org wrote:
[ http://issues.apache.org/jira/browse/MYFACES-316?page=all ]
Martin Marinschek closed MYFACES-316:
Thanks Mike Kienenberger for helping out, I just applied your patch.
Migrate component documentation from
On 7/13/05, Broekelmann, Mathias [EMAIL PROTECTED] wrote:
Thank´s for the info. I was already wondering about the few response for the
new datatable implementation. Hopefully it´s because happy users don´t cry ;))
I will test it again today, but I thought you were still fixing the bugs.
The
Ignore the subject part about the dataScroller.
My example doesn't have one and the problem still occurs.
I forgot to remove the dataScroller comment from the subject line
after determining this.
On 7/13/05, Broekelmann, Mathias [EMAIL PROTECTED] wrote:
Thank´s for the info. I was already wondering about the few response for
the new datatable implementation. Hopefully it´s because happy users don´t
cry ;))
On 7/13/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
I will test
On 7/14/05, Neal Haggard [EMAIL PROTECTED] wrote:
I need to be able to get the length of a collection in JSF EL. Is there a
way to do it? Looking at JSP 2.0 EL (which JSF uses) it allows for
functions, specifically the pre-defined length() function. However, when I
try using that with
Myfaces components link broken on web site:
The requested URL /components/overview.html was not found on this server.
been updated. You'll want:
http://myfaces.apache.org/tomahawk/overview.html instead.
NOTE: There is still a ways to go with the website adding new
information, removing eroneous information etc. but we'll get there.
sean
On 7/20/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
Myfaces
with that too.
My $0.02 worth.
TTFN,
-bd-
On Jul 21, 2005, at 10:12 AM, Mike Kienenberger wrote:
It takes 20 seconds for you to download them.
That doesn't mean it takes 20 seconds for others.
If they're only used for testing, don't download them unless you're
doing testing
This seems to get asked frequently.
It'd be nice if someone who implemented a working solution would
update the wiki with the process.
This is probably a good place to put it (I documented doing something
similar with pulldown menus here).
http://wiki.apache.org/myfaces/SubmitPageOnValueChange
Martin,
Maybe I'm doing something wrong, but the latest svn is breaking on
your change to AutoUpdateDataTableRenderer.java
==
entry
committed-rev=225559
name=AutoUpdateDataTableRenderer.java
text-time=2005-07-27T19:15:17.156250Z
What ever became of the codegen stuff?
I was hoping to submit a patch to automatically build a
myfaces.taglib.xml file for use with the facelets project, but I can't
seem to find it anymore.
facelet-taglib
namespacehttp://myfaces.apache.org/extensions/namespace
then - Sean, any comment
on that?
thanks,
Martin
On 7/27/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
What ever became of the codegen stuff?
I was hoping to submit a patch to automatically build a
myfaces.taglib.xml file for use with the facelets
I realize that MYFACES-330 is a pretty trivial patch, but maybe it
could be applied before it becomes un-applyable? :)
Codegen :) Why fight it?
On 8/4/05, Martin Marinschek [EMAIL PROTECTED] wrote:
Yes, this is a very good thing to do...
how do you want to do this? XSLT transformation?
regards,
Martin
On 8/4/05, Sean Schofield [EMAIL PROTECTED] wrote:
You know, of course, that the prefix
Both the wiki and the tomahawk docs have UISaveState as x:save_state.
This should be x:saveState, shouldn't it?
2005/8/9, Mike Kienenberger [EMAIL PROTECTED]:
Or even better, I'll check the RI as well, and submit a bug report there
too :)
On 8/9/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
How about I provide a patch where the behavior is identical unless a
String or Object converter
option, for
which I'd be willing to provide a performant patch.
-Mike
On 8/9/05, Craig McClanahan [EMAIL PROTECTED] wrote:
On 8/9/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
Yes, the current RI does the same thing, but the only documentation
of the behavior is a comment in a private message
PROTECTED] wrote:
On 8/9/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
I've opened a discussion on the JSR-RI dev mailing list on this topic.
So far, the argument against it is weak -- performance hit -- which
is just an implementation detail. However, someone may jump in with
more
I think the t:saveState description starts off too technical.
My opinion is that it'd be better to say what a user would use it for first.
Maybe something along the lines of:
t:saveState enables you to persist beans and values longer than
request scope, but shorter than session scope. It is
This seemed important enough to forward.
-- Forwarded message --
From: Ed Burns [EMAIL PROTECTED]
Date: Aug 15, 2005 12:20 PM
Subject: [NOTICE] Need Java SE 5.0 to build JSF now
To: [EMAIL PROTECTED]
Hello,
AS per EG discussion, I have modified jsf-api to introduce generics.
Sylvain,
Thanks! This solves some of the issues I reported yesterday on the
myfaces-user list when using the server-side mode.
Here's one place the control behaves differently, though.
When a request is submitted to the server, the control reverts back to
the default pane rather than the pane
, as
the client-side just hides the bug.
On Tue, 2005-08-16 at 13:17 -0400, Mike Kienenberger wrote:
Sylvain,
Thanks! This solves some of the issues I reported yesterday on the
myfaces-user list when using the server-side mode.
Here's one place the control behaves differently
Yep. Seems fine.
On 8/16/05, Sylvain Vieujot [EMAIL PROTECTED] wrote:
Yes, sorry, this was my second commit (doesn't queue event).
Should be ok now.
On Tue, 2005-08-16 at 14:24 -0400, Mike Kienenberger wrote:
It now preserves the tab, but the CommandLink I have on the tab
doesn't
not be too hard.
But still the problem you mentioned in user ML should still be fixed, as
the client-side just hides the bug.
On Tue, 2005-08-16 at 13:17 -0400, Mike Kienenberger wrote:
Sylvain,
Thanks! This solves some of the issues I reported yesterday on the
myfaces-user list
You're probably thinking of the message I forwarded to the myfaces dev
list earlier about JSF 1.2 requiring 5.0
-- Forwarded message --
From: Ed Burns [EMAIL PROTECTED]
Date: Aug 15, 2005 12:20 PM
Subject: [NOTICE] Need Java SE 5.0 to build JSF now
To: [EMAIL PROTECTED]
Hello,
cover it.
http://www.apache.org/foundation/faq.html#what-is-apache-NOT-about
==
What is Apache not about?
[...] to demand someone else to fix your bugs.
==
Mike Kienenberger commented on MYFACES-91:
--
[...] open source software works like
Yes, use the first parameter to associate messages with a specific UI element.
See this link for details:
http://wiki.apache.org/myfaces/Create_and_Display_Messages
Bottom half includes an example.
-Mike
On 9/12/05, Michael Jenik [EMAIL PROTECTED] wrote:
--- Michael Jenik [EMAIL
Ken,
You can't change the standard JSF api.
You'll need to create a tomahawk HtmlSelectManyCheckbox component instead
I recommend basing your patch on that.
On 9/15/05, Ken Weiner (JIRA) myfaces-dev@incubator.apache.org wrote:
Add ability to specify layout width for HtmlSelectManyCheckbox
I posted this awhile back on the user list, but what about the
possibility of a testing renderkit? The encoding would write
values to a Map, and the decoding would read them from a Map.As
was pointed out before, it might not work with AJAX, but it'd
certainly simplify a great deal of the
Is this supposed to be fixed in svn?
I just did a complete checkout about an hour ago, and built it with
ant dist-all and I'm getting the error below if I use myfaces-all,
but not if I use myfaces.api, myfaces.impl, and tomahawk separately.
java.lang.NoClassDefFoundError:
:25 PM, Bill Dudney wrote:
No I've not checked it in yet because I'm waiting for discussion on
the idea of making a 1_1_0 branch that we could do the emergency
release from.
TTNF,
-bd-
On Sep 22, 2005, at 1:20 PM, Mike Kienenberger wrote:
Is this supposed to be fixed in svn
I'm certainly no expert in making releases nor am I a committer, but
why start off being sloppy? There's a bug that warrants an immediate
release. There's no guarantee that another such bug won't turn up
after the next release and require another release. That's what
branches are for, so why
in all that but there has not
been
much discussion about it yet. I'd rather see some discussion
happen
before I check in the rest of the changes.
TTFN,
-bd-
On Sep 22, 2005, at 1:38 PM, Mike Kienenberger wrote:
It's got to be checked into the trunk at some
Yes, there's a showstopper regression bug in inputCalendar as well.
Still trying to see what revision it broke at, but likely either
289859 -- Martin's revamp on the 17-18th
289189 - Myfaces-569 fix on the 15th
Trying to download and build the revisions right before each to
determine when
version
wouldn't work?
regards,
Martin
On 9/23/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
If we're going to do a general release based on the current svn, I've
already run into one blocker issue that I'm still trying to track
down.
1.1.0 (just tested it) and before (Aug 16
Sean, this appears to be broken in the current trunk as well.
I'm trying to use the sandbox for the first time (graphicImageAjax),
and it's now skipping over the sandbox build when using ant by
itself.
I've manually applied your patch to what I checked out, and it's working.
On 9/28/05, [EMAIL
:35 -0400, Mike Kienenberger wrote:
Sylvain,
I'm definitely interested in a component that can display an image
from bytes as well, if you want any assistance.
-- need a dynamic image servlet is the next item on my todo list :)
On 9/26/05, Sylvain Vieujot [EMAIL PROTECTED] wrote
Vieujot [EMAIL PROTECTED] wrote:
Except if you serialize the image, the size of the image shouldn't be a
factor.
Did you try this with the sandbox application ?
Do you know the URL size limit in Jetty ?
Thanks,
Sylvain.
On Wed, 2005-09-28 at 15:30 -0400, Mike Kienenberger wrote
=09183912}
getContentTypeMethod=#{graphicImageAjaxBean.upImage.getContentType}
getBytesMethod=#{graphicImageAjaxBean.upImage.getBytes}/
So the URL would just have :
- The initializationParameters
- The viewId
- The componentId
On Wed, 2005-09-28 at 16:12 -0400, Mike Kienenberger wrote
Sylvain,
Just saw this posted elsewhere.
Maybe it'll be useful.
Performing a JSF GET
http://jroller.com/page/why?entry=how_to_do_a_jsf
It doesn't quite look like what you want, though.
On 9/26/05, Sylvain Vieujot [EMAIL PROTECTED] wrote:
Yes, you're right, but I was looking for a way to use
=#{graphicImageAjaxBean.upImage.getContentType}
getBytesMethod=#{graphicImageAjaxBean.upImage.getBytes}/
So the URL would just have :
- The initializationParameters
- The viewId
- The componentId
On Wed, 2005-09-28 at 16:12 -0400, Mike Kienenberger wrote:
Yes, I think you're right in that the size of the image
into problems under some cases?
On 9/29/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
What about the possibility of manually constructing a minimal
component tree and using that instead? Perhaps just a UIViewRoot and
a copy of the graphicImageAjax? The jsf state should be small enough
in that case
of an img
Thanks for your ideas,Sylvain.On Tue, 2005-09-27 at 12:35 -0400, Mike Kienenberger wrote:
Sylvain, I'm definitely interested in a component that can display an image
from bytes as well, if you want any assistance. -- need a dynamic image servlet is the next item on my
-09-29 at 11:31 -0400, Mike Kienenberger wrote:
Actually, I wonder
if the security issue is the same in both cases. I suspect if we
run through jsfstate through a 64 base decoder that we'll see the
method bindings as El strings already. I'm pretty sure that
the default saveState behavior
and neither work, which is even stranger.
-MikeOn 9/29/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
We can get the encoding behavior as seen in jsf state by calling the
encoding methods. There seem to be enough versions of them
:)
org.apache.myfaces.renderkit.html.HtmlResponseStateManager -- impl
I'm seeing duplicate jsf_state_64, jsf_tree_64 and jsf_viewid ids
with multiple forms on a page. Each form has all three ids. Aren't
ids supposed to be unique across a page?
At first I wondered if this was a facelets problem, but I see the same
behavior with a standard jsp page.
Sean, what's posted on http://cvs.apache.org/builds/myfaces/release/
is named 1.1.0. That's not correct, is it?
Hope you fix it soon or we're going to be trying to figure out which
1.1.0 people are reporting errors against :)
On 9/30/05, Sean Schofield [EMAIL PROTECTED] wrote:
Release
Should there be multiple copies of
org.apache.myfaces.config.MyFacesConfig.class in myfaces-all.jar?
I see three in the jar file I'm currently using. There's two copies
in the 1.1.1RC1 release.
Actually, I'm seeing multiple copies of a few files in the RC1 release
now that I've sorted by
, Mike Kienenberger wrote:
Should there be multiple copies of
org.apache.myfaces.config.MyFacesConfig.class in myfaces-all.jar?
I see three in the jar file I'm currently using. There's two copies
in the 1.1.1RC1 release.
Actually, I'm seeing multiple copies of a few files in the RC1
If that's the case, someone should update the
http://myfaces.apache.org/gettingstarted.html page with that version
requirement.
On 10/11/05, Brendan Conner (JIRA) myfaces-dev@incubator.apache.org wrote:
[
http://issues.apache.org/jira/browse/MYFACES-685?page=comments#action_12331841
]
I'd like to agree with Alexander on this one. Sometimes, it's better
to be able to tell end users that their pages will expire after 5
minutes (or 5 hours) rather than saying they can only backtrack 15
views (most end-users have no idea what a view means). Not all of
us need to tune our
Should JIRA be reconfigured with a different from/return-path value?
It's still sending out email as myfaces-dev@incubator.apache.org.
Return-Path: myfaces-dev@incubator.apache.org
Received-SPF: pass (gmail.com: domain of
myfaces-dev@incubator.apache.org designates 209.237.227.199 as
permitted
UIComponent.findComponent(String expr) is one way.
I thought there was a method on Application as well, but I can't seem
to find it again.
On 10/20/05, Travis Reeder [EMAIL PROTECTED] wrote:
I am wondering if there is a simple function somewhere to get an item by id
in the component tree?
That'd also mean that you couldn't use forceID from an alternate
ViewHandler facelets or Shale/Clay as well since the *Tag isn't used.
On 10/21/05, Travis Reeder [EMAIL PROTECTED] wrote:
Any reason for this? Why I ask is because when creating components
programatically, you can't setForceId().
HtmlResponseStateManager.decode64 is a private method. It can be
deleted now that you removed references to it.
On 10/24/05, Dennis Byrne (JIRA) dev@myfaces.apache.org wrote:
[
http://issues.apache.org/jira/browse/MYFACES-742?page=comments#action_12355639
]
Dennis Byrne commented on
As far as I know, you have to do all of this manually. Edit the
component, the tag, and the tld file.
The xml file is no longer used. I'm not entirely certain why they're
still around.
On 10/25/05, sharath reddy [EMAIL PROTECTED] wrote:
Hello,
I was looking to make some changes to the
and
method-binding.
regards,
Martin
On 10/25/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
As far as I know, you have to do all of this manually. Edit the
component, the tag, and the tld file.
The xml file is no longer used. I'm not entirely certain why they're
still around.
On 10
Set a breakpoint on the constructor.
Probably you're not saving the state of the onSuccess attribute, and a
new component is created without initializing that field.
On 11/2/05, Travis Reeder [EMAIL PROTECTED] wrote:
I have a page using HtmlSelectManyAjax that is built inside the bean,
not on
There's no choice in regards to JSF 1.2. JSF 1.2 already requires Java 1.5.
However, I'm definitely against JSF 1.1 requiring Java 1.5.
On 11/4/05, Keith Lynch [EMAIL PROTECTED] wrote:
This is certainly a large issue. Some products still have to support Java
1.3.
At ILOG I had major issues
Volker, I don't have any answers for you.
However, by moving the phase listener to after the apply request
values phase, you're still going to have the same issues with
validation that you had with InvokeApplication since end-users might
specify components as immediate=true.
On 11/5/05, Volker
It looks like there may be a couple of facelet-impacting issues here.
Take a look at this issue, where I've tried to describe both of them.
http://issues.apache.org/jira/browse/MYFACES-760#action_12357043
On 11/2/05, Martin Marinschek [EMAIL PROTECTED] wrote:
Wait a minute - Martin posted that
to the
user. You can see the initial results of this on the Form Fields
updated dynamically through ajax examples by putting in an invalid date
on the date text field.
Travis
On 11/5/05, *Mike Kienenberger* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Volker, I don't have any
Facelets does this already. Perhaps there's some ideas or code that
could be borrowed from that project.
On 11/11/05, Travis Reeder [EMAIL PROTECTED] wrote:
I would also love to see this, i know the pain. Another thing it could do
is try to recreate the tree a single time if a duplicate id is
Write a program that takes the JSF 1.1 and 1.2 docs, identifies the
docs that are NOT identical to JSF 1.1 docs, and creates a patch for
those that are the same.
Then you should have a significant amount of the javadocs without
using any JSF 1.1 docs :)
Then it's just a matter of writing docs
On 11/23/05, Sean Schofield [EMAIL PROTECTED] wrote:
For every 1 mistake you make you will be adding 99 pieces of valuable
documentation and someone will eventually catch the 1 mistake!
I agree. In fact, this is my practice in answering emails too. I
answer them even when I'm unsure, because
}/
/t:dataList
Will post to users (for new questions;) from now on.
-Tony
On 11/23/05, Mike Kienenberger (JIRA) dev@myfaces.apache.org wrote:
[
http://issues.apache.org/jira/browse/MYFACES-869?page=comments#action_12358398
]
Mike Kienenberger commented on MYFACES-869
with
no success. I will see if I can find some relevant threads or get help on
the users list. What I need is an iterating tag that renders its children
only.
Sorry again for the repost.
-Tony
On 11/23/05, Mike Kienenberger (JIRA) dev@myfaces.apache.org wrote:
[
http://issues.apache.org
Ok. Looks like it's just a client issue. The diff shown in my
commit message seems fine.
On 11/23/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
I'm doing a pre-commit diff of contributors.xml in (Windows) Eclipse
with subeclipse, and I'm seeing that every line is different, unless I
turn
Thanks, Martin.
It didn't affect my current situation, but it needed to be done for new files.
I've borrowed your words and added them to our wiki :)
On 11/23/05, Martin Cooper [EMAIL PROTECTED] wrote:
On 11/23/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
I'm doing a pre-commit diff
Should I be closing invalid or won't fix jira issues at the same time
I resolve them?
Is there a reason why we can't change all of these
org.apache.myfaces.tree2.xyz attributes to xyz?
// Tree2 attributes
public static final String SHOW_NAV=
org.apache.myfaces.tree2.SHOW_NAV;
public static final String SHOW_LINES =
good enough, but I did strongly consider INVALID :)
Thanks for commenting.
On 11/23/05, Simon Kitching [EMAIL PROTECTED] wrote:
Hi Mike,
Mike Kienenberger wrote:
Should I be closing invalid or won't fix jira issues at the same time
I resolve them?
I would personally have marked
the way you describe it.
sean
On 11/23/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
Is there a reason why we can't change all of these
org.apache.myfaces.tree2.xyz attributes to xyz?
// Tree2 attributes
public static final String SHOW_NAV
On 11/23/05, Wendy Smoak [EMAIL PROTECTED] wrote:
IMO it would be better to fix them and get it over with. Once they
have the 'native' eol style then it doesn't matter who edits them.
+1 -- it's got to happen eventually, and the sooner it's done, the
better. If possible, it'd be best to
Does anyone have a problem with me going in and removing unused imports?
SeverityDescription ResourceIn Folder Location
Creation Time
1 The import javax.servlet.http.HttpServletRequest is never
usedNavigationHandlerImpl.java
to false.
Maybe some of the other committers can comment on this.
On 11/28/05, Alberto Molpeceres [EMAIL PROTECTED] wrote:
On 11/28/05, Mike Kienenberger (JIRA) dev@myfaces.apache.org wrote:
[
http://issues.apache.org/jira/browse/MYFACES-882?page=comments#action_12358688
]
Mike
Sure. I'm not in any rush, so just let me know when.
On 11/28/05, Sean Schofield [EMAIL PROTECTED] wrote:
On 11/24/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
[snip]
The easiest solution (in my opinion) is to have the tag attribute
names and the component attribute names be the same
Ok. I see.
So you added svn:keywords with a value of Date Author Id Revision HeadURL?
Thanks for figuring it out and explaining it to me :)
On 11/29/05, Simon Kitching [EMAIL PROTECTED] wrote:
Mike Kienenberger wrote:
It looks like org.apache.myfaces.custom.schedule.* is missing svn
Simon,
I had to merge in the myfaces_sandbox.tld file changes I made, and it
looks like it may have missed some of your whitespace changes. Sorry
about that, but it's very difficult under Windows to detect whitespace
changes, since SVN whitespace differs from the checked-out whitespace
due to
Yeah, looks like SVN commits work differently than CVS commits in
Subclipse.In SVN, you have to manually reselect each new file to
commit them. How annoying.
On 11/29/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
Thanks, Simon.
That's the third time Eclipse Subversion has claimed
I also wasn't fond of yet another myfaces.jar, but I think the
advantages of releasing different versions of Tomahawk and Impl make
up for it. At some point, Impl should become stable and mature, but
hopefully tomahawk is going to constantly change and grow. I don't
think Impl and Tomahawk
+1 for a separate jar.
It's a good point that tomahawk should be split, just like jsf/core
and jsf/html are split out. All of the validators, converters, and
non-rendering components probably should go into tomahawk-core :)
[Guess we probably better not use myfaces-core, but like Bill said, I
On 11/30/05, Bruno Aranda [EMAIL PROTECTED] wrote:
If we split the components, we will need another prefix for
myfaces-core ('ft', 'f' from the standard core and 't' from tomahawk)?
I see many decisions in this thread now :-) So I also think that we
should avoid the name myfaces-core.
I'd
On 11/30/05, Simon Kitching [EMAIL PROTECTED] wrote:
[1] It would be interesting to know whether this approach would work for
Facelets; on first view, what is the timing of binding attribute
evaluations with respect to the aliasBean's rendering methods?
No one who is using facelets will use
I removed it as soon as I realized there was still a lack of clarity
on this issue.
However, (and I'm not a lawyer), the CDDL looks compatible with the
Apache license to me.
On 12/2/05, Abrams, Howard A [EMAIL PROTECTED] wrote:
A while back someone asked if ASF was reviewing CDDL to allow
Mathias,
Thanks for taking care of all of these! I wasn't aware of the issue
of handling non-String values before, and it looks like I was not
alone.
On 12/2/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
-return vb != null ? (String)vb.getValue(getFacesContext()) : null;
+
Sometime between 10/24 and 11/28, Myfaces stopped loading resources on
a page request with a new session fragment.
I'm guessing there must have originally been code to handle the
;jsession=* part of the URL that somehow was removed. Once the
session is created, (on the next request) the
Marinschek [EMAIL PROTECTED] wrote:
Yes, no one was.
It's a workaround, but it's awkward at least.
Still, it's better than nothing, and if it is in the Spec like this,
we'll need to implement it.
regards,
Martin
On 12/5/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
-1 for doing
Ed, I understand that you needed a short-term workaround, and I'm
overjoyed to hear you confirm to others that it's not in the spec this
way.
I still think our time (the Myfaces committers' time) would be better
spent creating a full solution rather than implementing the
workaround. The
Ok. Hearing no objections, or comments of any sort today, I guess
I'll go ahead and commit this change, and someone can change it back
if I'm wrong.
On 12/5/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
I'm looking into this, and it appears that the problem is that the new code
uses
Logging is always contentious. I'd rather we let the end-users
decide, and currently the standard for doing that in a framework is
to use commons-logging. We do need to clear up whether it's ok to use
it for the api jar file, though.
Our wiki currently reads:
I think there's some misunderstanding here about facelets. Facelets
isn't tied to any particular view technology (ie, html).
Facelets are based on HTML-designed JSP source code is untrue.
Facelets doesn't use tld files or (jsp)Tag classes. Facelets works
directly on the component class.
Code generation isn't currently used. Some of us have talked about
bringing it back, but we haven't gotten around to doing so yet.
Right now you have to grab it from
https://svn.apache.org/repos/asf/myfaces/impl/tags/before_svn_reorg
(I think that's the correct tag.) I'm sure a bunch of us
What's the process for getting the MyFaces web site updated?
I made a few documentation changes at the beginning of December as
well as adding documentation for two new sandbox components, but those
changes still haven't made it to http://myfaces.apache.org.
-typeorg.apache.myfaces.JSCookMenu/component-type
renderer-typeorg.apache.myfaces.JSCookMenu/renderer-type
/component
/tag
Adding the renderer-type, JSCookMenu should work with facelets.
Thomas
On 12/17/05, Mike Kienenberger [EMAIL PROTECTED] wrote
On 12/17/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
The ones I've heard the most complaints about in the past are tree,
tree2, and jscookmenu. But it's never been clear to me whether those
problems were solved. Unfortunately, these aren't components I'm
using.
Thomas, I am
On 12/19/05, Matthias Wessendorf [EMAIL PROTECTED] wrote:
so we could resolve this ticket ?
http://issues.apache.org/jira/browse/MYFACES-698
We can't close this issue yet, but Thomas is definitely making progress on it.
On 12/19/05, Adam Winer [EMAIL PROTECTED] wrote:
You (or Andrew Robinson) could check out the SetActionListenerTag code
I contributed to Facelets at:
I'm a bit confused why you're removing all of the javadocs that Simon
spent so much time writing. I can understand the usefulness of
putting a reference to the official javadoc specs, but it's far better
to have the documentation that Simon wrote plus the reference than it
is to have only the
Currently extensionsFilter.xml suggests the following configuration information:
filter-mapping
filter-nameMyFacesExtensionsFilter/filter-name
url-pattern*.jsf/url-pattern
/filter-mapping
filter-mapping
filter-nameMyFacesExtensionsFilter/filter-name
1 - 100 of 1572 matches
Mail list logo
