/ApplicationImpl.html
[2]
http://archive.apache.org/dist/myfaces/source/myfaces-core-1.2.9-src.zip
[3]
http://www.apache.org/dyn/closer.cgi/myfaces/source/myfaces-core-assembly-1.2.10-src.zip
Thanks,
Adam
- FHA 203b; 203k; HECM; VA; USDA; Conventional
- Warehouse Lines; FHA-Authorized
[EMAIL PROTECTED] wrote:
[...]
The problem is the updateActionListener doesen't execute when
immediate = true. but of course it does when immediate = false.
Is this as designed? It would be nice if the updateActionListener
would execute, so I could pass by the validator ins this case
AFAIK
not store it.
The RI, FWIW, does not save submittedValue, which should be a bug (and
is quite likely my fault!), but ADF Faces does in our input components
for exactly this reason.
-- Adam Winer
On Tue, 29 Mar 2005 03:14:18 +0200 (CEST), Jon Travis (JIRA)
[EMAIL PROTECTED] wrote
It's more than just the dummy form; it's also the auto-scroll Javascript, etc.
-- Adam Winer
On Mon, 28 Mar 2005 17:32:57 -0600, Heath Borders
[EMAIL PROTECTED] wrote:
I agree with removing the dummyform code from the
responsewriter.endDocument() method. I would say we could output
On Apr 1, 2005 12:28 AM, Manfred Geiler [EMAIL PROTECTED] wrote:
On Mar 29, 2005 12:54 AM, Adam Winer [EMAIL PROTECTED] wrote:
I've been shown some problems lately with MyFaces 1.0.9 and ADF Faces.
The problems specifically trace to MyFaces's use of
ResponseWriter.endDocument() to output
a slightly different way to solve this
in 1.2: h:form will have a prependId flag that can be set
to false.
-- Adam Winer
On Apr 1, 2005 11:07 AM, Martin Cooper [EMAIL PROTECTED] wrote:
So now that I know there is at least one ADF Faces person on this list (Hi
Adam! :) ...
I'd be very
, that endDocument() isn't
the right place for any of this code.
Cheers,
Adam
On Apr 1, 2005 1:39 PM, Manfred Geiler [EMAIL PROTECTED] wrote:
The autoscroll feature makes the browser page automatically jump down
(and right) to the place where the user had scrolled before a page
refresh
Is there a way to prevent myfaces from serializing whole view tree on
request?
When I edit a jsf page changeing something then those changes are not
reflected when tomcat is already running -- view tree is already
serialized in session and attribute changes in shown jsf components are
not
Why h:outputLink doesn't encodeURL() supplied value ? (or how to make
it to do this? :-))
Simple:
h:outputLink value=a b c d h:outputText value=link//h:outputLink
is rendered as a id=_id0:_id1 href=a b c dlink/a
IMHO spaces and other special characters could be encoded (excluding /
character).
.
-- Adam
On 8/20/05, Martin Marinschek [EMAIL PROTECTED] wrote:
Ok, I see.
What I remember of the MyFaces codebase, the UIComponent attribute is
set for the top-most html tag element (the one which is one to one
linked to the component), but not for the children tag elements.
e.g, for the table
think this is
in the spec, though I'm being lazy right now and not checking...)
Cheers,
Adam Winer
Congrats, guys. All the adulation is well-deserved! And let's all
give the team some time to rest on their laurels before worrying
about 1.2. :)
Cheers,
Adam Winer
On 9/14/05, Sean Schofield [EMAIL PROTECTED] wrote:
Also, why don't I see a big splash about you guys on TSS?
We're holding
Thomas,Does your forEach really work for all nested components? E.g., does it really work for h:panelGrid? For h:dataTable? I'd be rather surprised if it did, as forEach is not at all a simple thing to implement - you need to hook into the EL engine to do it properly.
-- AdamOn 10/3/05, Thomas
A couple of suggested improvements for the patch:- Perform the encoding check once, in the constructor, and save a boolean instance variable, to save lots of unnecessary String.equals() calls.- Support all of the Unicode encodings, which as of
1.4.2 were:UTF-8
UTF8
The single lamest thing is that the JSF spec doesn't explicitly say what methods should be supported.The second lamest thing is that the spec doesn't require that *all* methods be supported in all Maps, Lists, etc., across the board. I should've pushed that in
1.2, since it's been bugging me
And I finally got around to filing:https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=126Collections in JSF should be required to support all operations
-- AdamOn 10/6/05, Stan Silvert [EMAIL PROTECTED] wrote:
Ed has clarified sessionMap.clear() in the javadoc.
toWindows programming - was to use an ampersand, notan underscore. I can see why underscore would be more
appealing these days.-- Adam WinerOn 10/12/05, Udo Schnurpfeil [EMAIL PROTECTED]
wrote:Hi!At the moment we have 3 attributes regarding labels and accesskeys:
1. label 2. accessKey 3
It'd better be in the 1.2 spec somewhere, 'cause it's in the 1.2
RI code, API side. It's not RenderKit specific.
Check the getLabel() function in MessageFactory.
http://tinyurl.com/dpted
-- Adam
On 10/13/05, Bernd Bohmann [EMAIL PROTECTED] wrote:
Hello Adam,
i didn't found
(),
and then save off its two components.
Getting per-request state to survive redirect/, like Mario's proposing,
is a separate issue, as you say.
-- Adam
On 10/18/05, Mathias Brökelmann [EMAIL PROTECTED] wrote:
Well, I have not taken a look into the ri for this issue. So I can not
say
I'd suggest a Filter that synchronizes on a private Object stashed on
the HttpSession.
(In general, avoid synchronizing on the HttpSession itself).
-- Adam
On 10/18/05, Mathias Broekelmann (JIRA)
myfaces-dev@incubator.apache.org wrote:
[ http://issues.apache.org/jira/browse/MYFACES-543
is nowbetter supported because the user will see a NotSerializeableExceptionimmediatly if a value of the state is not serializable.
2005/10/18, Adam Winer [EMAIL PROTECTED]: What exactly do you mean by the serialized view is now really serialized (this was not the case before)?Before, server-side
these
days, which is a pretty good reason for him to be kind of
in absentia. :)
-- Adam
On 10/19/05, Simon Kitching [EMAIL PROTECTED] wrote:
Werner Punz wrote:
The main problem I see is if there is some kind of version interface
break, you
could end up with two different incompatible
his own problem without any API changes.
The only really legit use case for escape=false on a selectItem
is for something like selectManyCheckbox, if you wanted to
have HTML formatting in the label.
Cheers,
Adam Winer
On 11/8/05, Grant Smith [EMAIL PROTECTED] wrote:
OK, sandbox
to either resort to NCRs + escape=false or to entering
characters directly in the target character set.
And, my harsh answer to that problem is that developers should stop
using old-style .jsp file format, which is hideous, and use .jspx documents
instead.
-- Adam
On 11/8/05, Grant Smith [EMAIL
model
instances. It's not especially practical right now, because the
performance of a round-trip through the JSF lifecycle is too painful
for anything as granular as a single keystroke.
-- Adam
On 11/10/05, Travis Reeder [EMAIL PROTECTED] wrote:
Interesting thread, but I have to disagree
conventions, what's
the reason for putting Ajax in the name of these tags (or,
even worse, Java method names)? The abstraction
(asynchronous granular requests) is what matters, not the
latest rubric or the particular transport protocol.
Cheers,
Adam Winer
support for configuring multiple instances
of the FacesServlet with different lifecycles. Jacob's idea,
IIRC. (Craig hasn't been especially involved in the JSF
EG for quite awhile now.)
-- Adam
as a servlet config
parameter, not just a context init parameter.
-- Adam
On 11/15/05, Sean Schofield [EMAIL PROTECTED] wrote:
I think Craig was referring to the *current* ability to configure a
custom lifecycle. From the javadocs it looks like this is supported.
Can you clarify this some?
sean
the lifecycle is a good start, but it's not
a complete solution.
-- Adam
On 11/16/05, Martin Marinschek [EMAIL PROTECTED] wrote:
Sounds promising to me!
Even though from the perfomance tests that have been posted to the
mailing list a while ago, it doesn't look like going through the
lifecycle
be a consequence
of excessive short-term memory allocation.
-- Adam
On 11/16/05, Martin Marinschek [EMAIL PROTECTED] wrote:
Yes - this is what would be the best thing to do.
Jacob is calling this something like context-sensitive processing or so.
regards,
Martin
On 11/16/05, Sean
bundles provided by f:loadBundle will not be available
- Any EL expressions evaluated inside tags will not re-evaluate
-- Adam
On 11/16/05, Volker Weber [EMAIL PROTECTED] wrote:
Hi,
i just came over a problem with verbatim tags in ajax enabled components.
see:
http://www.mail-archive.com
to just AJAX-enabled
components, because then you end up needing to make this knowledge
pervasive across all renderers, which is awful. Optimizing some
renderers to be especially slick and cool at dealing with AJAX,
great.
Eventually, this might be the same problem as with what Adam has described
and likely to remain so.
Cheers,
Adam Winer
On 11/21/05, Simon Kitching [EMAIL PROTECTED] wrote:
Hi Travis,
I expect that the leading underscore in the name is there to explicitly
mark that that class is *not* part of the public API of this JSF
package. That's a fairly common pattern.
I'm
* required),
and prefixing can be turned of for UIForms too in JSF 1.2.
Subtract these two issues, and forceId isn't especially
necessary or useful.
Regards,
Adam
On 11/22/05, Sean Schofield [EMAIL PROTECTED] wrote:
Is there any particular reason why you can't just use forceId=true for
when you want
).
This whole mess is why I proposed JspIdConsumer for JSP 2.1,
which lets you do this reconnecting in a robust manner.
Cheers,
Adam Winer
On 11/23/05, Travis Reeder [EMAIL PROTECTED] wrote:
Does anyone have any comment on whether this is a bug or not:
As you can see UIComponentTag.doEndTag calls
I think Simon's question is not about why forceId exists
in the first place, but why AJAX would *require* its use.
The former was discussed long ago. The latter is a new
question which deserves careful consideration.
-- Adam
On 11/23/05, Sean Schofield [EMAIL PROTECTED] wrote:
Simon
is utter nonsense.
In regards to the bug here, the JSF 1.2 spec is explicit
that commandLink *can* use Javascript, and other components
(in the standard set, of course) may not. So this is not a bug.
-- Adam
On 11/29/05, Sean Schofield [EMAIL PROTECTED] wrote:
Al,
My rant wasn't really directed
it unnecessary to save state in *most* cases.
No, it's not sufficient; the examples get a little more contrived,
but you really do have to take the hit of saving this state if
you want correct behavior.
-- Adam
users are, unfortunately, stuck in an old HTML mindset and
are unwilling to use single forms for the entire page.
-- Adam
configuration. It bugs me, for instance, that in
J2EE 5.0, a user still has to explicitly register FacesServlet. Why?)
Of course, I'm open to any brilliant ideas out there. ;)
-- Adam
On 12/5/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
Ed, I understand that you needed a short-term workaround, and I'm
be necessary, but I'd feel a bit warmer and fuzzier when we get
around to taking this up in the EG if I could point at an exact scenario.
Thanks,
Adam
,
Adam
the question one way or the other. Overriding
getValueBinding() seems a bit odd to me.
-- Adam
On 12/9/05, Simon Kitching [EMAIL PROTECTED] wrote:
Hi Adam,
Thanks very much for taking a look at this patch.
I agree that when explicitly avoiding a return value the patch causes
two String header
critical
issue (and, like I said, without numbers, it's hard to prove
that it is critical.)
Cheers,
Adam
On 12/11/05, Simon Kitching [EMAIL PROTECTED] wrote:
Adam Winer wrote:
Fair enough, but as with most performance questions.
actual numbers are of the essence. I've had thoroughly
It's right, in that this is the behavior required by the spec.
It's wacky, in that the spec behavior (in this case, something
that Craig kinda chucked in without much EG discussion) is
something I've never cared for.
t:messages could add behavior that if detail==summary,
don't show both.
-- Adam
.
-- Adam Winer
On 12/13/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
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
On 12/14/05, Martin Marinschek [EMAIL PROTECTED] wrote:
Adam,
we haven't as we still have some open bugs which prevent working
Facelets perfectly with MyFaces. So this is a hen-egg problem. If we
got rid of those bugs, we'd use Facelets more, if Facelets was used
more, there might be someone
And since Jacob wasn't totally clear, you don't even have
to touch Tapestry-like views with Facelets. I don't.
Your pages can look just like .jspx files (minus jsp: stuff,
of course).
-- Adam
On 12/14/05, Adam Winer [EMAIL PROTECTED] wrote:
On 12/14/05, Martin Marinschek [EMAIL PROTECTED
TagAttribute.getValueExpression() (and wrap in a ValueBinding
adapter) instead of app.createValueBinding() (the value expressions
are cached and reusable).
-- Adam
On 12/19/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
If you want to also make sure you're supporting non-component tag
handlers for facelets, you
protocols like XmlHttp
JSF in its current form is a pretty good start, but it ain't all
the way there yet.
-- Adam
On 12/21/05, Jacob Hookom [EMAIL PROTECTED] wrote:
I have written quite a bit on this topic in relation to components and
CSS/XUL and the benefits of structual separation
This is very strange code, IMO. ViewHandler.createView() should
return a UIViewRoot with the viewId already set; that last statement
(viewRoot.setViewId(newViewId)) should be a no-op.
-- Adam
On 12/22/05, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
In NavigationHandlerImpl around line 145
do not set the viewId here
// ok, but the RI does so, so let's do it, too.
So we do call the viewRoot.setViewId(); in createView, but then call
it afterwards as well. Which really doesn't make any sense!
I'll get rid of the offending statement - Adam, can you check back
without having the
need for extra libs (commons-logging). Is this guaranteed if we only
use commons-logging within methods and there is no public/protected
API dependency in jsf-api?
Yes, this is guaranteed.
-- Adam
If yes, I'm -0 on that.
that lets you define optional interfaces on a RenderKit that'll
get called as needed by the ViewHandler - no private IP being
revealed here, just google ExtendedRenderKitService for
a taste of the idea :)
-- Adam
On 12/28/05, Glen Mazza [EMAIL PROTECTED] wrote:
Martin Marinschek wrote:
So what other
it is incorporated into the base set. (Small example: we
require JDK 1.4, and use JDK 1.4 logging. OK, or not? Not looking to
open the discussion on that one right now, just using it as an
example)
-- Adam
, and
east bay), pronounced oh-lone-ee)
- Miwok (the tribes in modern-day Marin and Sonoma. (Mee-walk)
- Siskiyou (Sisk-you)
- Piute (Pie-yoot)
-- Adam
On 12/28/05, Werner Punz [EMAIL PROTECTED] wrote:
Martin Marinschek wrote:
Name discussion again - sounds funny ;)
We've had a hundred
If we wanted to continue with T, Trinidad? Though that
might be a bit unfair to Tobago, Trinidad being the much larger
of the two islands making up the nation of TT.
-- Adam
On 12/28/05, Adam Winer [EMAIL PROTECTED] wrote:
I actually never much liked Cherokee - if we're gonna go
viewIds
that are mapped to internal code - this way, we can have
components that show specific popups without forcing the
user to install JSPs.
-- Adam
On 12/28/05, Werner Punz [EMAIL PROTECTED] wrote:
Adam Winer wrote:
My assumption is that the initial arrival will be akin to Tobago,
part
://tinyurl.com/b2n2t
-- Adam
On 12/28/05, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi *,
I've implemented a proposal for partial validation and model update.
Essentially what I've done is I've given the commandLink and
commandButton a new attribute, actionFor. This attribute is a
comma
download ADF Faces for now... :)
We should get the process of merging together the component sets finished
ASAP.
I think the first priority should be making sure the component sets
work together!
-- Adam
the UI, and are not really
model-based, and these generally won't have validation rules.
-- Adam
Well, ya could just download ADF Faces for now... :)
I can't bring in ADF Faces now - Open Source is precondition on this one...
regards,
Martin
code - our custom
ViewHandler is an adapter only; we're still using ordinary JSPs
- and Facelets - for our rendering. I don't see that specifically
as being of great concern.)
-- Adam
the corresponding section accordingly - so
required isn't needed.
-- Adam
, mostly to get client-side
validation into the mix.)
-- Adam
On 12/30/05, Volker Weber [EMAIL PROTECTED] wrote:
Hi,
the problem is (or was, i didn't check this recently) that the
UIViewRoot is *not* created via application by the RI implementation,
but tobago needs to have his own UIViewRoot
is not transparent and diverse, the
quality of the code won't matter.
Ted,
I totally understand, and agree - open source is more than just,
well, opening the source, and without fully open communications
and an interested and involved community, this wouldn't work.
-- Adam
are all under a single umbrella,
we can work at reducing our set of ViewHandlers to just one with
well-defined plugin points, which'd help go a long way towards
getting our component sets working together. (Integrating the
ResponseWriters would be a big second step.)
-- Adam
UIViewRoot.getLocale() should never be null; ViewHandler.calculateLocale()
should see to that. (Of course, some developer might explicitly call
UIViewRoot.setLocale(null), but they'd deserve what they'd get...)
I'd recommend Approach 2 in general.
-- Adam
On 12/31/05, [EMAIL PROTECTED
Werner,
ADF has some technology that may be helpful here (when
it arrives, grumble, grumble...)
http://tinyurl.com/999qe
http://tinyurl.com/7vn42
Cheers,
Adam
On 1/3/06, Werner Punz [EMAIL PROTECTED] wrote:
Actually this all or nothing or common ground approach is not what I had
in mind
them.
Where Craig says it would be better than nothing (referring
to alphabetical order), I agree in so far as making it a convention,
but I argued against making it part of the spec, since it's not
something I wanted to be stuck with for the rest of eternity.
-- Adam
On 1/5/06, Werner Punz
.
-- Adam
And, once we get to JSF 1.2, provided is a clear
winner because web containers will need to provide a JSF
implementation.
-- Adam
On 1/6/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 1/6/06, Adam Winer [EMAIL PROTECTED] wrote:
Anything that's a compile time dependency of library Foo
where
to be redone the right way.
Looking forward to all of your comments!
Best regards,
John and Adam
, and variables inside a single top level object.
apart from that, the javascript code in the functions themselves
looked pretty decent to me. Any chance we can work together to clean
that up in incubator?
Absolutely! (Incubator, sandbox, whereever...)
-- Adam
regards,
Martin
On 1/7/06
have been to happy ;)
*sigh*
I'd hoped for better from Oracle. Oh well. I guess there's work to do...
The good news is that we know better now. :)
-- Adam
off of
#{adfFacesContext} (plus #{processScope}, which is our only
other top-level variable).
-- Adam
On 1/9/06, Simon Kitching [EMAIL PROTECTED] wrote:
Adam Winer wrote:
One
of the items already on our todo list is moving all the functions,
classes, and variables inside a single top level
On 1/7/06, Sean Schofield [EMAIL PROTECTED] wrote:
John and Adam,
Thanks for all of your hard work getting this ready. I'm looking
forward to studying it. I'm a little busy with the Maven migration
now but I will get to it. Once we are fully migrated to maven I
suspect this will make
org.apache.myfaces.custom
to separate the renderers, tags, and components? org.apache.myfaces
already does this for the ext stuff. Or, more generally, separating
further the things that are used internally in MyFaces from things
we expect developers outside of MyFaces to rely on?
-- Adam
On 1
when calling
through to event listeners on children.
-- Adam
On 1/9/06, Mathias Broekelmann (JIRA) dev@myfaces.apache.org wrote:
[
http://issues.apache.org/jira/browse/MYFACES-1010?page=comments#action_12362262
]
Mathias Broekelmann commented on MYFACES-1010
received all the paperwork they need
to make it official. Maybe Ted can answer that?
-- Adam
On 1/9/06, Martin Marinschek [EMAIL PROTECTED] wrote:
John, Adam,
do you have any news that your code grant has already been processed?
That will be the next bureaucratic step we'll need to take, I think
On 1/9/06, Simon Kitching [EMAIL PROTECTED] wrote:
Adam Winer wrote:
@Matthias, I'd rather not have any wrappers - the plan here
is to repackage in line with MyFaces rules. I would, however,
strongly like to keep the high-level concept of separating our
public APIs - like component
Thanks, Ted. So we'll get our ducks in a row during the rest
of January, and maybe I can also take the time to help orient
some folks around the code base.
-- Adam
On 1/10/06, Ted Husted [EMAIL PROTECTED] wrote:
On 1/10/06, Bill Dudney [EMAIL PROTECTED] wrote:
Since Ted seems to be busy I
Thanks Bill!
-- Adam
On 1/10/06, Bill Dudney [EMAIL PROTECTED] wrote:
http://people.apache.org/~bdudney/apache-drop.zip
is the url of interest
the old url should not work any more.
Thanks for pointing that out Ted.
TTFN,
-bd-
On Jan 10, 2006, at 9:05 AM, Bill Dudney wrote:
Sorry
on the server.
-- Adam
On 1/11/06, Martin Marinschek [EMAIL PROTECTED] wrote:
1) you say JSF file - you mean js, right?
On 1/11/06, Cagatay Civici [EMAIL PROTECTED] wrote:
Hi Martin,
I am working on integrating the client validators to tomahawk now and have a
couple of questions, hope
- but moving
forward, java.util.logging is the standard, and that's what MyFaces
should use, even if log4j has technical advantages.
-- Adam
Well, although I think that log4j is the best logging solution, IMO we
must not force it upon MyFaces end users.
So, I still think that commons-logging is the best
On 1/11/06, Simon Kitching [EMAIL PROTECTED] wrote:
Adam Winer wrote:
On 1/11/06, Manfred Geiler [EMAIL PROTECTED] wrote:
2006/1/10, Korhonen, Kalle [EMAIL PROTECTED]:
If one really wants to combine java logging to log4jLogs, I'd think you
should be able to fairly easily write a java log
,
and that's it: how could the row identifier meaningfully apply
to that return value?
-- Adam
On 1/25/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Yes, ok.
but then, the scoped-id is something which should also work with row
identifiers. And - there should be a way to lookup a scoped identifier
(and the developer
experience, by making PPR so easy.)
Do you - additionally to sending the client-id to the client- send the
scoped id as well?
Nope.
@Adam: well, findComponent does not work if the component is a child
component in a dataTable, and IMHO it should, that's my basic issue
here.
It does
really does need to use postback for all requests, for funkier requirements
like saving temporarily entered results. And you could do so without
forcing users to change back from outputLink to commandLink.
-- Adam
On 1/27/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I don't think the problem
BTW, a credit-where-it's-due: I should be clear that my idea's
always been... completely omits that this idea is very much
due to John Fallows!
-- Adam
On 1/27/06, Adam Winer [EMAIL PROTECTED] wrote:
My idea's always been something like an optional
NavigationHandler interface:
public
component.
-- Adam
On 1/26/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Hmm
yes, you're right - we could do that.
but of course, Jacob is right in that the user might expect something
for their javascript methods as well.
and I am sure as soon as we change that, we'll get 15
That only gets you about a third of the way there, since JSF
isn't giving you a decent semantic way to generate meaningful
GET requests in the first place.
-- Adam
On 1/27/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 1/27/06, Martin Marinschek [EMAIL PROTECTED] wrote:
outputLink doesn't
Conversations and ADF processScope come to mind.)
-- Adam
On 1/27/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
That's an interesting solution-- with webwork, it allows EL (OGNL) evaluation
of URIs, so across the board, we could do something like:
navigation-rule
from-view-id/foo.jsp/from-view-id
instances, but in a more optimized fashion.
-- Adam
On 1/27/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Now that's exactly what I try to implement here. A version of
find-component working with stamped components like dataTable and
tree.
What I'm working on: if you give it a rowIndexed
...
-- Adam
On 1/27/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi Adam,
Of course - every component which does something special will need to
handle this in its special way. Only the component knows about this
stuff in JSF - a component is a blackbox is a blackbox is a blackbox
;) and should
it and see how it goes,
because we all benefit from seeing a diversity of approaches.
-- Adam
On 1/28/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Plus: that would also fix Adam's problem with:
parent.getChildren().remove(comp)
cause you are working on the actual component instance.
regards
,
and the source page, generating the query parameter.
... which is why a good solution to the problem involves a really smart
navigation handler (plus other parts of a JSF system) that can automate
the generation of such URLs *and* the inteilligent consumption on the
target page.
-- Adam
On 1/28/06
of
customizations without code changes, and is one of the features
that'd be great (IMO, 'course) to roll out across the MyFaces
component set.
-- Adam
On 1/31/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi Hagay,
we'll need to wait on that a little bit more - Oracle is about to open
source
dependencies. I've been wondering if I'd need to rip these
out (and would rather not have to, but will if needed.)
Thanks,
Adam
On 2/7/06, Dennis Byrne [EMAIL PROTECTED] wrote:
I don't need it, but an implementation requires this minimum.
Didn't realize this report was only for tobago, in which
On 2/13/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Well, members we could bother that come to my mind are:
Geir Magnusson
has been already helpful for MyFaces regarding TCK
Craig R. McClanahan
Mister JSF :-)
No offense to Craig, but the real Mr. JSF is Ed Burns!
-- Adam
I think it was John Fallows that told me there's a way to set up
Maven2 to add in a Maven 1 repository. Dunno the details,
and obviously it'd be better to have it as a full maven 2
artifact including the pom.
-- Adam
On 2/14/06, Sean Schofield [EMAIL PROTECTED] wrote:
Are there plans
1 - 100 of 721 matches
Mail list logo
