There were a few of us that wanted to push back on the WebTier EG around
annotation support over the fact that there wasn't a clear API
provided-- yet oddly enough, everyone is ending up with basically the
same API :-)
My hope is that the WebBeans JSR can bring some solidarity around this
Haimberger
On 2/25/07, Jacob Hookom [EMAIL PROTECTED] wrote:
This seams a bit odd:
private TreeStructComponent
internalBuildInitalTreeStructureToSave(UIComponent
component,FacesContext facesContext, Object state, int childIndex)
{
Object myState = null;
Map facetStateMap = null
This seams a bit odd:
private TreeStructComponent
internalBuildInitalTreeStructureToSave(UIComponent
component,FacesContext facesContext, Object state, int childIndex)
{
Object myState = null;
Map facetStateMap = null;
List childrenStateList = null;
if (state
If you are using jspx compilation, use 'and' instead of '' in EL
Volker Weber (JIRA) wrote:
[ https://issues.apache.org/jira/browse/TOBAGO-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475034 ]
Volker Weber commented on TOBAGO-287:
I might be missing the scope of everything, but just on initial glance:
ServletResponse response = (ServletResponse)
externalContext.getResponse();
ServletRequest request = (ServletRequest) externalContext.getRequest();
Locale locale = viewToRender.getLocale();
the statefull nature of JSF is
most
obvious problem of this technology.
I wonder if we can come up with some solution within latest spec or we
must postpone this till rise of JSF 2.0?
Best,
Igor.
Jacob Hookom wrote:
Adam Winer (Oracle ADF), Ed Burns (JSF Co-Spec Lead), and myself
talked about
as you always added the same components-- allowing optimization of
savestate for redundancy of components).
Jacob Hookom wrote:
It would be fine, just not included in the eden state-- Facelets would
provide the eden state, then at the time of savestate, it would be
compared to the passed component
,
the mailing list form break the whole form when you were trying to submit
only the login form -- because it's all one big form now?
Jacob Hookom wrote:
JSF 1.2 standardized on the identifier: javax.faces.ViewState, previous
versions of JSF 1.1 (myfaces and RI) each had their own identifiers
which
Adam Winer (Oracle ADF), Ed Burns (JSF Co-Spec Lead), and myself talked
about this in combination with Facelets at JavaOne last year, we
actually have some numbers generated:
http://weblogs.java.net/blog/edburns/archive/2006/05/javaone_video_a_1.html
(video, excuse my Minnesota slang)
the
rendered Base64 string *is* the viewstate and not just some identifier.
-- Jacob
Thanks a lot.
Jacob Hookom wrote:
If it's like the RI, the reasoning is to accommodate the back button issue
with server-side state saving. It would be wrong to assume/associate a
single state with a page
JSF 1.2 standardized on the identifier: javax.faces.ViewState, previous
versions of JSF 1.1 (myfaces and RI) each had their own identifiers
which caused difficulties for component developers
lightbulb432 wrote:
What is the purpose of the hidden field named javax.faces.ViewState, and how
does
The goal with JSF 1.2's rendering is that the ViewHandler, while it
builds the view, shouldn't render anything at all. So using JSP as your
view or Facelets as your view, the act of evaluating those artifacts
shouldn't push anything to the response.
Once you have the full component tree from
current solution depends on the
prefix being different from the Servlet id prefix.
-Original Message-
From: Jacob Hookom [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 12, 2006 11:51 PM
To: MyFaces Development
Subject: Re: Ids in 1.1.3 and 1.1.4
Unique Id generation aside, I think
Unique Id generation aside, I think the qualm was with the 'jsp' prefix
in the generated IDs. I know that JSP 2.1 has the ability to assign ids
unique to a tag on a page, but that's different than what you are
describing.
Martin Marinschek wrote:
The problem is that there is a bug in the
It looks like you have a good usecase setup for showing the error, but I
don't think the selectOneRadio component should enforce the use of a
converter if the value is not a string-- EL can handle putting anything
to a String without explicit converters.
[cc'ing MyFaces Dev]
-- Jacob
Mike
-SNAPSHOT
Environment: Facelets, JBoss Seam
Reporter: Jacob Hookom
Priority: Blocker
http://svn.apache.org/viewvc/myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlResponseWriterImpl.java?view=markup
Sometimes ResponseWriters are used to supplement
-1
1.2 setPropertyActionListener will be using value/target, otherwise
there would be 3 different sets of nouns to associate with this
functionality
Matthias Wessendorf wrote:
hey,
I'd like to rename the value/property attributes to from/to.
Makes more sense to me. since this tag is used
, Jacob Hookom [EMAIL PROTECTED] wrote:
-1
1.2 setPropertyActionListener will be using value/target, otherwise
there would be 3 different sets of nouns to associate with this
functionality
Matthias Wessendorf wrote:
hey,
I'd like to rename the value/property attributes to from/to.
Makes more
I should mention that TC 6 Jasper was implemented with the unified EL to
a point where the RI 1.2 demos ran fine and development of .tag files
with the new EL also worked with JSF 1.2
Stan Silvert wrote:
Most of what I did relies on Unified EL. In fact, the EL integration is
completely
Stan's cycles aside, it's probably just a case of JBoss wanting to have
all of their ducks in order for their next AS release. Going with the
'stable' RI 1.2 right now is one issue they don't need to worry about in
the immediate future.
That's not to say that JBoss couldn't easily switch over
Stan, did you get anywhere with Remy on separating out the javax.el
implementation from Jasper?
Adam Winer wrote:
ADF Faces has now been checked in at:
http://svn.apache.org/repos/asf/incubator/adffaces/trunk/adf-faces/
Everything has been repackaged into org.apache.myfaces subdirectories,
Travis Reeder wrote:
With the XML solution, how would you capture content written
directly to the response vs. content from multiple components?
If I understand what you are asking correctly, I may have already
answered it above with multiple responses from multiple components.
(no body) instead of a 200.
I have been using the response header as a poor man's Map for a few months w/
non-faces and faces requests and it hasn't bit me yet.
Dennis Byrne
-Original Message-
From: Jacob Hookom [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 2, 2006 08:29 PM
I'll be checking the facelets upgrades in soon, but to handle the
'multiple' case below, I use request/response headers instead of writing
to the body of the response. This allows many components to return many
types of responses without issue of formatting the body-- each
component/clientId
I know the world doesn't revolve around JSF, but you are promoting them
as JSF components-- :-)
I agree that the RPC approach (Shale/Seam Remoting) is extremely valid,
but as a mashup with a UIComponent, there's an obvious disconnect.
That's my only point, why should one EL expression work
Sean Schofield wrote:
Can you elaborate on what exactly is buffered in the JSP case. I have
a rough idea of what you are talking about here but I don't know
enough about the internals of JSP to completely understand this. I'm
interested in some more specifics here.
With using JSP (or any
One thing you could also promote is to stick to classes for styling--
the 37Signals guys do this, leaving identifiers up to server-side code
and promoting re-use of content.
Matthias Wessendorf wrote:
damn,
just tested. Firefox shows the div as green, but IE not.
thanks for pointing it out,
I think where the performance shows up is that with JSP, you are
buffering a lot of non-component data on each call, so the
'instructions' for your tree have to be re-evaluated with each request.
When you get into AJAX or partial processing, this can get expensive!
With Facelets, we have a
by vistors in the form of ELResolvers which provides a *very*
flexible way of
mapping back to models within MVC. Now lets do the same for MVC
controllers.
-- Jacob
Jacob Hookom wrote:
The NavigationHandler has that default behavior. But much like
WebWork
allows the pluggable ActionMapper
into a common mind share within JEE.
-- Jacob
Don
Sean Schofield wrote:
[Moving this aspect of the discussion from myfaces to struts list ...]
On 4/7/06, Jacob Hookom [EMAIL PROTECTED] wrote:
Covered here a bit:
http://weblogs.java.net/blog/jhook/archive/2006/03/the_new_servlet_1.html
Covered here a bit:
http://weblogs.java.net/blog/jhook/archive/2006/03/the_new_servlet_1.html
Mario Ivankovits wrote:
Hi!
what would be the representation used for a date/long/double in a
string? Can we look into the xsd definition for that? Would an xsd
type representation converter be
I guess I look at this stuff much differently with JSF. Watching Ted
Neward's interview on SOA
(http://www.theserverside.com/news/thread.tss?thread_id=39757), it got
me thinking that these AJAX solutions are doomed to pursue the same route.
If we setup a good story for partial
Dennis Byrne wrote:
I guess I look at this stuff much differently with JSF. Watching Ted
Neward's interview on SOA
(http://www.theserverside.com/news/thread.tss?thread_id=39757), it got
me thinking that these AJAX solutions are doomed to pursue the same route.
[OT]
I have only
Craig McClanahan wrote:
I was constrained in the stuff so far by what could be accomplished at
runtime -- and there's no way to define a tag library on the fly at
that point. But what you're describing could certainly be done by
processing annotations at compile time instead (using apt or
(this doesn't happen in the RI).
--
Jacob Hookom - Minneapolis
JSF-EG, JSF-RI, EL, Facelets
A lot of this is occurring with JSF 1.2 and the Avatar proposal for
partial processing of the component tree.
Oracle's ADF components too have the concept of triggers/observers today.
Travis Reeder wrote:
Hi all,
Been a bit out of the loop for the past few weeks, I am just wondering
if
phase.
Has anyone tried this yet? Would it be possible, and are there any
pitfalls?
regards,
Jurgen
--
Jacob Hookom - Minneapolis
JSF-EG, JSF-RI, EL, Facelets
Components
Blog: http://www.orablogs.com/jjacobi
--
Jacob Hookom - Minneapolis
JSF-EG, JSF-RI, EL, Facelets
I've added compiler support for deferred expressions within Tomcat 6.
While there's still more to do (round .tag files at least), I am able to
run the RI 1.2 samples without problems.
--
Jacob Hookom - Minneapolis
JSF-EG, JSF-RI, EL, Facelets
I've added support for deferred EL to Tomcat 6 as part of JSP 2.1.
While there's still more work to be done (around .tag files for one), I
am able to run the RI 1.2 samples without problems.
--
Jacob Hookom - Minneapolis
JSF-EG, JSF-RI, EL, Facelets
JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
Jacob Hookom - Minneapolis
JSF-EG, JSF-RI, EL, Facelets
for Apache MyFaces
--
Jacob Hookom - Minneapolis
JSF-EG, JSF-RI, EL, Facelets
if the renderer does a conversion.
So what Dave wants ought to work. In the latest nightly build and
several before them.
regards,
Martin
On 2/12/06, Jacob Hookom [EMAIL PROTECTED] wrote:
findComponent has nothing to do with client ids. They work off of
different logic.
Martin Marinschek (JIRA
NamingContainers, even if they
don't extend UIData?
Thanks!
Jacob Hookom wrote:
But doesn't that break spec?
Are you returning the UIComponent itself or some proxy instance?
Martin Marinschek wrote:
Yes - but I extended the findComponent concept for data table to allow
scoped id's with a row
, Jacob Hookom [EMAIL PROTECTED] wrote:
The reason why I ask is that we are trying to correct this for JSF 1.2,
and I'd like to know if you've come up with an alternate, working solution.
Example:
UIComponent cA = root.findComponent(_id0:mytable:4:text);
UIComponent cB = root.findComponent(_id0
Thanks Martin!
Martin Marinschek wrote:
Yeah.
that would be my feeling.
You treat the component much more like the blackbox it is with that.
regards,
Martin
On 2/12/06, Jacob Hookom [EMAIL PROTECTED] wrote:
Thanks Martin,
So your feelings are that the API would be better served
();
--
Jacob Hookom - Minneapolis
JSF-EG, JSF-RI, EL, Facelets
present in
the spec.
regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
Jacob Hookom - Minneapolis
JSF-EG, JSF-RI, EL, Facelets
.
form:data:1:input
is the client-id if rowindex is set to 1 and
form:data:input
is the client-id if rowindex is set to -1.
No clue how I am supposed to work around that, except with different
separators.
regards,
Martin
On 1/22/06, Jacob Hookom [EMAIL PROTECTED] wrote:
I think it's a great idea
then.
Whatever solution you decide to use, it wont save the world ;-)
Ciao,
Mario
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
Jacob Hookom - Minneapolis
a wrapper for the properly initalized
and pre-configured component-instance then?
Where's the source for Avatar? In the JSF-RI?
I'll need to do that right now, though, and so probably without API changes ;)
regards,
Martin
On 1/21/06, Jacob Hookom [EMAIL PROTECTED] wrote:
This ties somewhat
Ed kind of did his own thing-- not sure what he wrote or where it's at.
Martin Marinschek wrote:
I've looked into the glassfish web-cvs tree under jsf-extensions, and
not found the sources.
Have they been moved?
regards,
Martin
On 1/21/06, Jacob Hookom [EMAIL PROTECTED] wrote:
Yeah
definition.
Regards,
Simon
--
Jacob Hookom - Minneapolis
JSF-EG, JSF-RI, EL, Facelets
and
Courses in English and German
Professional Support for Apache MyFaces
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
Jacob Hookom - Minneapolis
--
http
Professional Support for Apache MyFaces
--
Jacob Hookom - Minneapolis
--
http://hookom.blogspot.com
,
Martin
On 11/27/05, Jacob Hookom [EMAIL PROTECTED] wrote:
I've noticed in your recent releases that you've included a lot of
write-behind code within the JSP View Tag. What was the reason for
spreading the logic around between the individual component renderers,
JSP tags, and the JspViewHandler
? Would be great!
And - for clarification, are you just talking about the view-tag, or
also about other tags as well? I didn't quite get this from your post,
you talk about the view-tag first, and then it rather sounds general?
regards,
Martin
On 11/27/05, Jacob Hookom [EMAIL PROTECTED] wrote
build persistence
layer) and its really a time saver - now we moved to hibernate JSF
and thus I'll build this again, but now with the hope that others can
benefit from this too.
Jump in!
---
Mario
--
Jacob Hookom - Minneapolis
--
http://hookom.blogspot.com
then the impl. So we can compile
against older versions that might be in the third party J2EE distros
(like JBoss). Anyways, the point is that Maven may finally provide
the best solution to this problem so far.
Thoughts?
sean
--
Jacob Hookom - Minneapolis
--
http
://www.w3.org/TR/REC-html40/struct/objects.html#adef-alt
Should we do anything about this?
Cheers,
Simon
--
Jacob Hookom - Minneapolis
--
http://hookom.blogspot.com
I've noticed in your recent releases that you've included a lot of
write-behind code within the JSP View Tag. What was the reason for
spreading the logic around between the individual component renderers,
JSP tags, and the JspViewHandler implementation? The state write-behind
could have just
Versions: 1.0.9 beta
Environment: Tomcat, FireFox/Mozilla Browser
Reporter: Jacob Hookom
Assigned to: Martin Marinschek
Priority: Critical
Fix For: Nightly Build
The contract between ViewHandler and RenderKit for creating a ResponseWriter is
that the ViewHandler should suggest
[
http://issues.apache.org/jira/browse/MYFACES-441?page=comments#action_12319853
]
Jacob Hookom commented on MYFACES-441:
--
If the renderkit is going to allow a content type of xhtml, then it needs to
produce xhtml compliant JavaScript, which I don't
[
http://issues.apache.org/jira/browse/MYFACES-441?page=comments#action_12319858
]
Jacob Hookom commented on MYFACES-441:
--
Great! Thanks a ton!
CLONE -HTML Renderkit doesn't choose correct ContentType (JavaScript
--
From: Jacob Hookom [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Date: Aug 9, 2005 3:07 PM
Subject: Shale Tapestry Integration
To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Cc: Matthias Wessendorf [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED], [EMAIL PROTECTED]
mailto
Neal Haggard 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 I get an exception
Adam Winer (ADF Faces) committed quite a few changes this evening and
I'm going to work on preparing another release tonight/tomorrow. He
mainly focused on JSF 1.1 support for MyFaces and the extensive ADF
functionality.
One feature that we are looking at is being able to have a complete
it.
Thanks for keeping us updated!
One thing: there is a licensing issue if we would want to use your
technology in MyFaces - now I'd like to ask just theoretically: is
there any way you would be able to change licensing to a less
restrictive license?
regards,
Martin
On 7/7/05, Jacob Hookom [EMAIL
dependency is *new* EL for JSF1.2 and JSP 2.1 ?
if so ... does glassfish currently contain a jsp 2.1 web container?
-Matthias
On 7/7/05, Jacob Hookom [EMAIL PROTECTED] wrote:
I will check licensing with Sun after their break. The licensing has
more to do with the new EL-API dependencies from
/7/05, Jacob Hookom [EMAIL PROTECTED] wrote:
I will check licensing with Sun after their break. The licensing has
more to do with the new EL-API dependencies from Glassfish than it does
with the JSF-RI.
-- Jacob
Martin Marinschek wrote:
We have just been discussing your
currently contain a jsp 2.1 web container?
-Matthias
On 7/7/05, Jacob Hookom [EMAIL PROTECTED] wrote:
I will check licensing with Sun after their break. The licensing has
more to do with the new EL-API dependencies from Glassfish than it
does
with the JSF-RI.
-- Jacob
Martin Marinschek wrote
hoping that people will download it and give it a try. I'm looking
for any feedback and ideas on steering the features that Facelets will
include before its 1.0 release.
All the Best,
Jacob Hookom (JSF EG/Glassfish)
72 matches
Mail list logo
