Hi!
java.lang.ClassCastException:
org.apache.myfaces.shared_impl.renderkit.html.util.DummyFormRequestInfo
at
org.apache.myfaces.shared_tomahawk.renderkit.html.util.DummyFormUtils.getDummyFormParameters(DummyFormUtils.java:121)
at
Hi!
I'm still very much in favour of *not* shipping a common jar used by
both core and tomahawk (and maybe tobago, ADF, etc); the versioning
issues related to that are nasty.
Why? Once the shared api is stable this should not be a big issue, no?
I've already moved stuff to tomahawk to reach
Hi Martin!
the question is - do we need and want it in impl?
I dont need it there - but it only moves the problem away FOR NOW, it
will arise again - I bet. The interoperability is still broken.
I can refactor (again) to put the dummyForm stuff into tomahawk - Who
needs this nasty dummyForm
Hi Martin!
where things are breaking right now is exactly where we have been too
lenient in the beginning and have made tomahawk to be based on impl
where it shouldn't.
Ok, but then, lets make it clean NOW. On the trunk - once we are
finished we can restart with the release.
Ciao,
Mario
DummyForm was a special feature of MyFaces, that was wrongly put into
the implementation - it should have been put into tomahawk, where it
belongs to.
Right?
+1
As for what that means for the release, I'd say we should get as much
of this refactoring into the release as possible, and
Manfred Geiler schrieb:
Please think of the two libs shared_impl and shared_tomahawk as two
*different* things.
OK, I'll restart my brain and try again ;-)
Let's look at the
key of the problem here: Why is it an issue when shared_impl and
shared_tomahawk have different FQN-Strings during
Hi!
I just want to collect what should be done to make shared clean:
I think the following should be moved to tomahawk:
JavascriptUtils
DummyForm*
MyfacesConfig
What else?
---
Mario
Hi Sean!
NOTE: Crucial fixes should go on the *branches* only. I will merge
them down to the trunk later. The worst thing you can do is fix them
on both.
And here we are again ;-)
As you might have read we still have serious problems with the structure
of shared and have to refactor
Hi!
If a patch is critical enough that it has to be put into a release
branch, then someone needs to make the time to insure it's merged
correctly -- and this hopefully is the exception rather than the rule.
Either that, or a new branch is needed.
Branches should be static once created so
No one?
I just want to collect what should be done to make shared clean:
I think the following should be moved to tomahawk:
JavascriptUtils
DummyForm*
MyfacesConfig
What else?
I see a problem with moving DummyForm out, though, it cant stay there.
Actually the dummyForm stuff works
Hi Manfred!
There are actually two questions to solve:
* should we move DummyForm to tomahawk at all?
At least we have to move DummyForm out of shared as it didnt work in
this refactored environment. I already wrote about the problem.
If the answer to the first question is yes the answer
Hi!
Currently the base classes for the command* tags (in shared) implement
the functionality of dummyForm, this is why its not needed to have the
overloaded renderer stuff and why it works with h: and t:
Sorry for being slow-witted.
There is no difference. If the user overwrites the
Hi!
URL: http://issues.apache.org/jira/browse/TOMAHAWK-195
Could someone with more maven knowledge have a look at it please.
I guess there is some parsing missing.
Thanks!
Ciao,
Mario
tried this yet? Would it be possible, and are there any
pitfalls?
regards,
Jurgen
--
mfg
Mario Ivankovits - OPS EDV Vertriebsges.m.b.H.
Software Engineering
Michael-Bernhard-Gasse 10, A-1120 Wien
Tel.: +43-1-8938810
Fax: +43-1-8938810/3700
E-Mail: [EMAIL PROTECTED]
Skype: mario_ivankovits
Hi!
Modified:
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/ajax/api/AjaxDecodePhaseListener.java
URL:
Hi!
So does anyone have any objections to my new branch creation?
I am fine with it. We use a current snapshot in our production
environment and it works.
---
Mario
Hi!
Could one please review my commit r390142 (see commits@).
It is a try to throw an exception if one add more then one child to a
facet. I've done this after I 2 hours of searching a problem in our
application just to figure out it was due to multiple facet children.
The if (id) stuff is
Hi!
I thought about creating some logic to detect if a ExtensionFilter is
configured.
To archive this, I'll add - say in HtmlFormRenderer (dont know the exact
name now, any other component will be fine too) in encodeStart something
like:
if (not checked in session)
{
new
Hi!
Didn't the extensions filter at one time put a flag in the request as it came
in? This would solve both use cases wouldn't it? Then you wouldn't even
need to parse the dd.
Yes, you are right.
So for the use case where the extensionsFilter buffers and parses the
response I can check
BTW - why didn't continuum catch this?
It was in for a couble of hours, so maybe continuum didnt run in the
meantime (given your mail time something around 3 hours )
---
Mario
I got this build error on a clean co of current.
OK guys ;) No 1.5 stuff in core until JSF 1.2 ;)
Ooops, sorry. Shoudnt use 1.5 for development ... damn newbie fault :-(
I've seen you already fixed it. Thanks!
Ciao,
Mario
Hi!
I dont want to be an asshole - so sorry in advance :-) -, but maybe we
should find a standard how to name our context configuration parameter
names.
In the past we had the scheme org.apache.myfaces.X where is
upper case only.
Now I've seen we got some new configuration parameters
Craig McClanahan wrote:
Personally, I can't see this issue being a useful place to become
pedantic :-).
Sure, you are right, but on the other hand this can easily be solved and
so I'll propose to change it.
It looks more professional if we have a clean way - the configuration is
one of the
Hi!
3) create a new component, which takes the values out of the request,
and reapplies them either to another component, or the managed bean.
It could look much like the aliasBean today.
Ok, finally I think this is not that bad idea :-)
It defines the possibilities within the view (which is
Hi!
Why do we need a component to take values out of the request and
apply them to a managed bean? JSF managed-beans can do this
right now without putting anything in the component tree.
As the example shows, it allows us to attach converter and validators.
Not every property of a managed
Hi!
I'm getting compiler errors when trying 'mvn install' with a clean
checkout of the HEAD revision of myfaces.
The method isCheckExtensionsFilter is in the MyfacesConfig class
however, so I can't immediately figure out how to solve this.
There must be something wrong with your maven. Maybe
Hi!
Forgive me if this has already been brought up, but what about URIs 255
chars?
This is why I proposed to route the real link generation through some
sort of interface.
That way we can provide a service like TinyURL - so the url size is no
longer a problem here.
Since even a long url
Its more what do the http spec say about URI size limits - and how
long might it take to have browsers with higher limits spread out.
rfc 2616 only *warns* about the 255 limit, and places no limit on the
protocol itself, leaving this up to the server or any intermediary. I don't
Martin,
John (I think) suggested to do it in the navigation rules of the
faces-config.xml, but there it will be implementation specific, except
you get it in the spec.
With some tricks we might get this in in an custom NavigationHandler, no?
Ciao,
Mario
Hi Martin!
the navigation handler doesn't read in the configuration. Reading in
the configuration is implementation specific, AFAIK.
since it works only with redirect only maybe this hack might do it:
public void handleNavigation(final FacesContext facesContext, String
fromAction,
Hi Jurgen,
+public class HtmlFishEyeList extends HtmlPanelGroup
I am not sure which direction you would want to go with this toolbar,
but maybe you can reuse parts of the tomahawk.navmenu framework?
At least it might be great to use NavigationMenuItem for configuration.
Just my 2ct.
Ciao,
Hi!
Just to make sure we talk about the same.
We have the place where we create a bookmarkable link - which can be the
NavigationHandler - and we have the place where we have to process the
incoming get parameters.
You can either put that metadata in the view - where it doesn't fit well - or
Hi!
Well, you definitely need some validation. I'm not positive
that JSF converters are totally the right way to go, because (generally)
converters are Locale dependent and user-readable - whereas
URL parameters must be Locale independent.
Thats a good point, but ...
EL coercion is
more
[EMAIL PROTECTED] schrieb:
From experimenting with going stateless in JSF, and Adam's work on state
saving deltas, we allow the view to be created up front with Facelets-- from
file-- fresh on a request. So even without any viewstate passed, you
basically get a snapshot of the same,
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 a good solution for this?
No need to do anything special other then fixate the locale/encoding
used (configureable
Hi!
But when starting up the Application and visit the first JSF-Page
I get the following Exception:
javax.servlet.ServletException: ExtensionsFilter not correctly configured.
Wo-ow - did this make it into the branch? I thought I checked it in
AFTER the branch - or do you use myfaces
Hi!
http://myfaces.apache.org/tomahawk/extensionsFilter.html
Thanks alot, I searched a page but didnt find it - shame on me - I'll
change it.
Ciao,
Mario
Hi!
I made some additions to shared required by tomahawk.
Now, as soon as I commit them, its no longer possible to build tomahawk
head against shared branch.
I know, there is shared_impl and shared_tomahawk made exactly to avoid
this conflict - but it works only at runtime - not at compile time
Hi!
I made some additions to shared required by tomahawk.
Now, as soon as I commit them, its no longer possible to build tomahawk
head against shared branch.
Why are you doing this? You should be building tomahawk trunk against
the shared trunk. Am I missing something here?
In
Mike Kienenberger schrieb:
On 4/11/06, Mario Ivankovits (JIRA) dev@myfaces.apache.org wrote:
We need to update the documentation.
I dont know when this changed and who it was, but the ExtensionsFilter is
required to add the javascript required by myfaces e.g. to handle the
scrolling stuff
Hi!
On 4/11/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
Ok, so I'll check if the ExtensionsFilter is available (its part of
tomahawk) - and if not, this feature is disabled (and a warning logged).
If this is sufficient, I'll give that a try.
If we're planning on keeping
Hi!
It looks like this solution works with myfaces head, have to take a look
how to get it into the branch too.
I think Sean is going to make a new branch tonight so you won't have
to worry about it if you get it in before then.
Ok, so its committed now. I hope I havent overlooked
Hi Sean!
I think Sean is going to make a new branch tonight so you won't have
to worry about it if you get it in before then.
Is this a core change? If so it should go on the *existing* branch
(and not the trunk.) If its on the trunk please back it out so I can
merge down from the
Hi Sean!
No - its in shared.
And no - I cant add it to the branch as there are already additions for
tomahawk in the same class.
Are we talking about r393309? If so this looks pretty
self-contained. Its not immediately obvious to me why this revision
can't be added to the branch
Hi
You seem like the person to approve the patch I wrote for auto-focus.
Sorry for being ignorant, but whats the value for the user to have the
focus reset on the last action component?
Could you please explain this a little bit for me.
If, I would like to have the focus set on the first
sharath reddy schrieb:
Ok, I see that NavigationMenuItems already has a List
attribute. I could probably use this. I can submit a
patch.
Great!
BTW, below is the license from the original files. I
am sorry if I seem to be a bit naive about license
issues
No problem, licensing stuff is
Hi Lyon!
You never got back to me on this.
Yes, sorry!
What do you think? I am willing to help
add this functionality to the sandbox focus component if that is where you
think it should go but I think it should go with the auto-scrolling stuff
for accessibility reasons (i.e. no mouse).
I
Hi!
What about Mario's fix 2 hours ago? (see Jira)
:-D
I dont know which date jira shows, but I patched it for about half an
hour ago.
I already told Sean about it and he prepares a new TCK test cycle.
Ciao,
Mario
Hi!
Now that everything has been merged down I
think this branch should be killed.
Any objections?
My last patch is not merged down, shall I commit it there?
Ciao,
Mario
Oh, you didnt mean shared, sorry, I'll stop computing for today ;-)
---
Mario
Now that everything has been merged down I
think this branch should be killed.
Any objections?
My last patch is not merged down, shall I commit it there?
Ciao,
Mario
Hi Mike,
Hey Mario.
I notice that ADD_RESOURCE_CLASS doesn't output the default value in
the warning like CHECK_EXTENSIONS_FILTER does. Instead it outputs a
class name.
Well, ADD_RESOURCE_CLASS outputs its default value. This value indeed is
the FQN of the class handling the resources.
Sean,
1.) Branch tomahawk now (even before the core vote is finalized.)
This requires to branch share too, tomahawk head already requires stuff
from shared head which is not in the 2.0.0 release.
I already expressed my thoughts about this in another post: Every time
we release core or
Hi!
I still think we
always need to branch before a release so we make sure that no last
minute problems are created by all of the ongoing work.
Yes this is still required, my hope is we manage to shrink the release
cycle from weeks to a handful days.
---
Mario
Hi!
+0
Why do we bundle the dependencies too? Shouldnt we take them as provided?
And do we have permission to bundle jstl?
Ciao,
Mario
Hi Martin,
welcome back - hope you had a nice vacation :-)
we can just add the license to the licenses section of sandbox, should
be ok.
Apache do not allow to have anything else then ASF license in their
repositories, no?
And only a handful of licenses (out of my brain its only BSD) are
Dennis Byrne schrieb:
So what do you mean by add the license to the licenses section?
There is a licenses dir under src/main/resources/ for most projects.
Oh, I see, wasnt aware that this is allows, tough, even better :-)
Thanks!
Ciao,
Mario
Hi!
Sorry for jumping in that lately, but ...
So DummyFormUtils has to move from tomahawk to shared or at least two
components will not work in the release ?
dummyFormUtils triggered my brain ;-)
I refactored all the stuff from shared to tomahawk, so - please do not
refactor DummyForm
Dennis Byrne schrieb:
Do you just want to take these two issues then? It looks like TreeTable has
the same problem as well BTW.
Got them.
Ciao,
Mario
Hi!
I have fulfilled all the license obligations and also
implemented your suggestion of using
'NavigationMenuItem' for the dynamic configuration.
Please let me know if there are any more issues...
Thanks! I'll have a look at is soon.
Ciao,
Mario
Hi Werner!
Jesse Alexander (KSFD 121) schrieb:
Do you mean replicating the tomahawk-components or different
components under the tomahawk-sign?
Different components, I have had this idea for some time now.
Sorry, I dont like this idea.
I dont know, why you think facelets are
Hi!
I was referring to the problems the user have with old libs in their
directories - with a clear package name in the game, we could more
easily find out where the problems are. But I can wait until after the
release, sure.
On the other hand we have to decide which burden we can put on
Hi!
I dont know, why you think facelets are speedier. They use exactly the
same renderer class, no?
Actually they are faster, but that is not my point, my point was to
enable easier component editing
and having a good set of components built upon an easier component tech.
For sure,
Werner Punz schrieb:
A seam like conversation system as tag
+infinite
a seam-less ejb3 opensessioninconversation filter built upon the
conversation system
+infinite
:-D
Ciao,
Mario
/mwessendorf
mwessendorf-at-gmail-dot-com
--
mfg
Mario Ivankovits - OPS EDV Vertriebsges.m.b.H.
Software Engineering
Michael-Bernhard-Gasse 10, A-1120 Wien
Tel.: +43-1-8938810
Fax: +43-1-8938810/3700
E-Mail: [EMAIL PROTECTED]
Skype: mario_ivankovits
Hi!
Figured out one issue regarding some Tree2 pages
tree2.jsf renders, but clicking on a document
I get this messasge
snip
java.lang.IllegalStateException: facet already has a child associated.
current component id: foo:clientTree:0:1:t2x
I already fixed it in myfaces-api head on
Hi Sean!
Is this fixed in the branch as well?
Which branch? tomahawk? This is a bug in myfaces-api! So we cant fix it
in tomahawk.
Sorry!
Ciao,
Mario
Hi!
This is a vote to release Tomahawk 1.1.2 (and its dependencies:
MyFaces Shared 2.0.1 and MyFaces Maven 1.0.2.)
+1
There is a non-trivial issue (TOMAHAWK-373) but this requires another
core release. I think the best thing to do is to release tomahawk
with this problem and quickly
Hi!
For the upcoming conversation tag I need some enhancements to the form,
commandLink, commandButton and outputLink components.
Also a redirect should be catched (through a responseWrapper in
ExtensionsFilter).
The requirement is to provide a way to globally add request parameters
to these
Hi Martin!
we'll have one, or even two volunteers for this ;).
Ok - so - where are they ;-)
Ciao,
Mario
Thomas Obereder schrieb:
I'm a volunteer for implementing this.
Great, thanks!
Ciao,
Mario
Hi!
The way I've implemented this sort of thing - getting request
parameters onto URLs pointing to JSF URLs - is by
hooking ViewHandler.getActionURL(). Would this
work for this scenario?
Good point, sure this might work too for the current scenario.
But then, in case of forms, they are
Hi!
I don't see that as a major problem, but it's simple to fix if it is. Just
parse the URL in the FormRenderer and extract query parameters in it
into hidden values. I wrote some code a few years ago that did
just that.
So we still have a renderer replacement? Than the advantage of your
Adam Winer schrieb:
So we still have a renderer replacement? Than the advantage of your
solution is lost.
No, it's not lost: first up, I think that could be done right in
FormRendererBase
without any portability. Even if you didn't do that, one tweak to
form is far, far
better han
Hi Martin!
just for me to clarify this for myself - if we trod down the path
proposed by Adam, how do we get out of a conversation again?
Yes, this is something which come into my mind too. Its always the same,
you can create a conversationTag without too much hassle, and then such
a detail
Hi!
In JSPStateManagerImpl NPEs might happen (I think in conjunction with
DummyForm) if SerializedViewCollection.add will be called more than once
per page.
Which is a documented behaviour in DummyFormUtils.
The reason is, that the _keys list will contain the same key more than
once than, now,
Hi!
If we rely on our affectedAjaxComponent approach (seeking comp and
calling methods on it) we are little bit restricted in coding.
If this mean that we can update only one component per request, then I
would like to see to at least extends this approach.
Beside the fact that a component
Hi (Martin)!
I added stuff so that we are able to show the real exception in an
custom error page instead of the generic ServletException.
You can configure such an custom error page in your web.xml (but for
sure, you all know this)
I did this for our tomahawk-samples. The custom page is named
Hi!
This is holding up the release because of a method not found error.
I am running low on time right now so I would appreciate it if others
can look into this also.
Which package? Shared or core? I agree, this should be fixed ASAP. I
will try to find time tomorrow but its better if
Hi Sean!
I know, you'll start to hate me, but today a serious problem come up
which I already fixed at 28.4.2006 but committed it only to head and not
the branch.
I posted a question on the developer list about this fix, but no one
answered and so I lost track of it.
This bug will happen if one
Hi!
Shall I merge this fix up now?
head works fine for me
+1 for merge
Ok, I am short of time today, so I didn't wait about any additional vote.
Its merged-up now, feel free to revert if you didnt like this
fix/workaround.
Ciao,
Mario
Hi!
I developed Faces Freeway to archive this dynamic generation:
http://facesfreeway.l3x.net/sample.html
The samples are not up to date, much more can be done already.
For those wanting to browse the source code:
http://facesfreeway.l3x.net/xref/index.html
It extracts metadata from your entites
Hi!
http://facesfreeway.l3x.net/xref/index.html
The xref is not up-to-date, please use the svn
http://l3x.net/svn/facesfreeway/trunk/ to skim through the source.
Ciao,
Mario
Hi Sean!
Pssst ... what's the work around?
See the JIRA issue. Use client side state saving
this is a workaround - even if not an adequate one as - depending on the
rest of the configuration - a change to client side state saving must
not necessarily work.
or [change]
Hi Alexander!
But more interesting task is to extract data straight from the
business layer. Data can come not only from RDBMS, but from
web-services or other place. I've been thinking that we can provide
access to data model for UI through general interface like extended
Maps and Lists. Add
Hi Martin!
there is nothing to be said against taking on Alexander for a SoC
project with his proposal, and then together decide on how much of
this fits into Faces Freeway, and let Alexander adopt the rest.
what do you think?
Yes, for sure, thats what I wanted :-)
Ciao,
Mario
Hi!
Currently it is not possible to put the datascroller on TOP of a table.
e.g.
t:dataScroller
/t:dataScroller
h:dataTable
...
The reason is, that the dataScroller will always see the previous
dataModel due to the caching of the model in UIData.
This cache will be cleared in UIData's
Hi Greg!
t:dataTable
f:facet name=header
t:dataScroller
[snip]
Worked for me.
Yes, I know that this will work, but I wont use the header/footer for
this. I'll say this is a workaround.
Ciao,
Mario
Hi Linda!
but my japasper
report for PDF and Excel format don't work any more,
H. Do you set the contentType on the response? e.g. to
application/pdf for pdf.
That way the extensionsFilter should not try to parse the binary output
and it should work again.
Report file
Hi!
Dennis, I don't think that a vote is necessary now. Just get the jsf
1.2 stuff up and working (EL, TCK, ...). We will do the vote as soon
as we are ready to merge the new code down to the trunk.
How long do we think this might take?
We should be aware that we have to do bug fixing on two
Hi Burno!
i try to deploy the latest release of MyFaces (and tomahawk) on Weblogic 8.1
sp 5 and i have this issue :
java.lang.IllegalStateException: strict servlet API: cannot call
Are you sure, you use the latest tomahawk release, the ExtensionsFilter
class changed to
Hi!
As you might know I moved the dummyForm stuff out of shared to tomahawk
due to some problems we had with it after introducing the shared_* stuff.
To still have the same functionality I installed the custom renderers
(for commandLink/commandButton) in tomahawks faces-config.xml
Now it turns
Hi!
Dummy Form is used by some of the custom navigation
menus such as NavigationMenu2, JsCookMenu, etc.
Ok, I know what DummyForm does and what its main intention is, but one
can always embed a component in an h:form.
What I dont know is, why we provided such a comfort to not require the
Started a new topic to concentrate the post DummyForm stuff and
TOMAHAWK-416 in one place.
How can we make the DummyForm stuff RI compatible (given that we still
think we need it)
Well, we have to override the renderer, but cant count on anything else
than encodeBegin/encodeEnd/encodeChildren
Hi Sean!
Can you be more specific on how this breaks things.
You cant easily replace renderers like commandLink/commandButton as you
do not know how their inner logic works and there are no specifications
how to name parameters and which should go to hidden fields or not and
which javascript to
Hi Martin!
so if there is no form in the parent-tree - you just render a form
around the link itself?
yes.
I really don't like the dummyForm stuff at all anymore.
+1 - so my proposed solution will provide a slow migration away from it.
At the end, I want to find a solution where we
*G*
so if there is no form in the parent-tree - you just render a form
around the link itself?
yes.
It turns out that this wont work too.
I tried to lookup the h:form renderer (through
context.getRenderKit().getRenderer) and the original link/button
renderer using reflection
Hi!
I know it's not this clear-cut, but the end result (even if it takes
some intermediate workarounds like generating wrapping form
components) should be to require these things to be inside a form.
Yes, I am completely with every who thinks we should deprecate the
dummyForm at all.
As I
*damn*
I fell like a complete idiot ... it is also not possible to intercept
the ViewHandler.
Reason: you never ever have the view in hand before it will be rendered.
Rendering and view creation happen at the same time with JSP.
So no way to change the view before it were rendered - now I think
So, for now I removed the renderer override in faces-config.xml so parts
of tomahawk should work with RI again.
If a user still wants to use the dummyForm he/she can add this [1] code
to the faces-config.xml
Its still time to rollback this change, else I'll post tomorrow
something to the user
Hi!
Sorry.
I wont put any additional effort into the dummyForm stuff as I think
this useless stuff.
Sorry if this sounds too harsh, dont know a better english wording yet ;-)
Once we have the chance to have the view in hand before rendering e.g
like facelets, or the upcoming SoC project it is
101 - 200 of 974 matches
Mail list logo
