Matthias, if you are in need for extensive dojo examples check their
unit tests they cover pretty much the entire library.
(including all the widgets)
Werner
Matthias Wessendorf schrieb:
ah,
I was looking for a sample like this
On 2/17/06, Gerald Müllan [EMAIL PROTECTED] wrote:
Hi,
regression: Since 1.1.1, JSFs can't send raw data to response
-
Key: MYFACES-1130
URL: http://issues.apache.org/jira/browse/MYFACES-1130
Project: MyFaces
Type: Bug
Versions: Nightly
Reporter:
thanks,
i have an struts based input suggest, so I'd like to switch to dojo
for that as well ;-)
-Matthias
On 2/17/06, Werner Punz [EMAIL PROTECTED] wrote:
Matthias, if you are in need for extensive dojo examples check their
unit tests they cover pretty much the entire library.
(including
HtmlTree : Cookie value retrieving issue
Key: MYFACES-1131
URL: http://issues.apache.org/jira/browse/MYFACES-1131
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: 1.1.1
Reporter: Guillaume Doumenc
Hi!
I tried to mark
http://issues.apache.org/jira/browse/MYFACES-1002
as fixed but failed due to the absence of any close/fix or whatever link.
Could one please adjust my permissions accordingly. JIRA User: imario
Thanks!
Ciao,
Mario
Maybe Manfred can help ?
On 2/17/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
I tried to mark
http://issues.apache.org/jira/browse/MYFACES-1002
as fixed but failed due to the absence of any close/fix or whatever link.
Could one please adjust my permissions accordingly. JIRA User:
From my tests comparing client and server state, I must say client-state
will not even scale to medium traffic...
The performance hit with client state was horrendous. processing time
was up to 5 times higher than with server-state. And the memory
footprint
was not significantly lower.
We
[ http://issues.apache.org/jira/browse/MYFACES-1002?page=all ]
Matthias Weßendorf resolved MYFACES-1002:
-
Resolution: Fixed
make tree.js work without navImageId
Key: MYFACES-1002
[ http://issues.apache.org/jira/browse/MYFACES-1002?page=all ]
Matthias Weßendorf closed MYFACES-1002:
---
make tree.js work without navImageId
Key: MYFACES-1002
URL:
[
http://issues.apache.org/jira/browse/MYFACES-1023?page=comments#action_12366763
]
Samuel ROBERT commented on MYFACES-1023:
Hello,
I had the same problem, when using the jodatime converter
(http://l3x.net/imwiki/Wiki.jsp?page=Joda),
which works
[
http://issues.apache.org/jira/browse/MYFACES-1023?page=comments#action_12366767
]
Mario Ivankovits commented on MYFACES-1023:
---
Nice to see someone uses my joda converter ;-)
I'll have a look at it.
inputCalendar with CalendarConverter loses
[
http://issues.apache.org/jira/browse/MYFACES-1023?page=comments#action_12366768
]
Mario Ivankovits commented on MYFACES-1023:
---
I think the problem with the joda converter is it do not implement the
DateConverter (also introduced by me ;) )
[
http://issues.apache.org/jira/browse/MYFACES-1131?page=comments#action_12366770
]
Guillaume Doumenc commented on MYFACES-1131:
This is due to the fact that for root (is state not transient) then there is
not path. To fix it, just validate
Hi all,
Sean already posted some thoughts recently. I know we should bring out
our next release first, but meanwhile we could have some thoughts
about future JIRA structure and version management.
Here is a short roundup of what we have:
MyFaces (sub-)projects on the site:
API
Impl
Commons
Hi Martin!
I added you to the developers group in jira.
Thanks!
Ciao,
Mario
to
org.apache.myfaces.commons.*
yes, why not.
I'm not sure at all if this is a good idea. Probably not ;-)
Just wanted to know what others think.
hehe, was just thinking the same
What about tomahawk ?
o.a.m.custom.* -
o,a.m.tomahawk.*
and for sandbox?
o.a.m.tomahawk.sandbox.*
or
On 2/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
to
org.apache.myfaces.commons.*
yes, why not.
I'm not sure at all if this is a good idea. Probably not ;-)
Just wanted to know what others think.
hehe, was just thinking the same
What about tomahawk ?
o.a.m.custom.* -
fileupload
--
Key: MYFACES-1132
URL: http://issues.apache.org/jira/browse/MYFACES-1132
Project: MyFaces
Type: Sub-task
Components: Tomahawk
Environment: jboss4, windows xp sp1,
Reporter: Seshireddy G
Hi,
I am facing a problem with fileupload. I am
Well tomahawk just branched now too so we might be safe to refactor at
this point. It won't impact the upcoming core or tomahawk releases.
My suggestion is that we start with commons first and see how that
goes. I can't think of anything where the class name would be
hard-coded. Why don't we
pps. Use svn move to do this so we don't lose our history
Does anyone know if IntelliJ does svn move behind the scenes when
moving (refactoring) classes?
Thanks,
Manfred
+1 from me. definitely.
regards,
Martin
On 2/17/06, Arvid Hülsebus [EMAIL PROTECTED] wrote:
Normally it does, but there are some limitations. I will ask Udo when he
is back -- in about 30 minutes. He gained some experience restructuring
our repository for the donation of the Tobago source.
I would like to add the following to the myfaces-master pom:
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.3/source
target1.3/target
It looks like he had only problems with older versions of IDEA or the
Subversion client. We can't report any problems with IDEA 5.1.
Regards,
Arvid
Martin Marinschek wrote:
+1 from me. definitely.
regards,
Martin
On 2/17/06, Arvid Hülsebus [EMAIL PROTECTED] wrote:
Normally it does, but
Adding tableSuggest feature to inputSuggestAjax
---
Key: MYFACES-1134
URL: http://issues.apache.org/jira/browse/MYFACES-1134
Project: MyFaces
Type: Improvement
Components: Sandbox
Versions: Nightly
[ http://issues.apache.org/jira/browse/MYFACES-1134?page=all ]
Gerald Müllan updated MYFACES-1134:
---
Attachment: tableSuggest_feature.patch
the patch to this issue
Adding tableSuggest feature to inputSuggestAjax
[ http://issues.apache.org/jira/browse/MYFACES-1135?page=all ]
Gerald Müllan updated MYFACES-1135:
---
Attachment: ajaxInput_impr.patch
the patch for this issue
Adding new features to inputAjax component
--
Adding new features to inputAjax component
--
Key: MYFACES-1135
URL: http://issues.apache.org/jira/browse/MYFACES-1135
Project: MyFaces
Type: Improvement
Components: Sandbox
Versions: Nightly
Reporter: Gerald
Just do the svn move manuall. Its not too hard.
On 2/17/06, Arvid Hülsebus [EMAIL PROTECTED] wrote:
It looks like he had only problems with older versions of IDEA or the
Subversion client. We can't report any problems with IDEA 5.1.
Regards,
Arvid
Martin Marinschek wrote:
+1 from me.
[ http://issues.apache.org/jira/browse/MYFACES-1135?page=all ]
Martin Marinschek closed MYFACES-1135:
--
Fix Version: Nightly
Resolution: Fixed
Thanks to Gerald Müllan for this.
Adding new features to inputAjax component
[ http://issues.apache.org/jira/browse/MYFACES-1134?page=all ]
Martin Marinschek closed MYFACES-1134:
--
Fix Version: Nightly
Resolution: Fixed
Thanks to Gerald Müllan for this.
regards,
Martin
Adding tableSuggest feature to
[ http://issues.apache.org/jira/browse/MYFACES-1133?page=all ]
Martin Marinschek closed MYFACES-1133:
--
Fix Version: Nightly
Resolution: Fixed
Thanks to Gerald Müllan for getting this fixed.
Tying InputSuggestAjax to dojo
Yes, I think that it is better to follow some convention. In my case,
I never use public in interfaces (to me it looks like using abstract)
;-)
Bruno
On 2/16/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
If nothing else, including public (and excluding
abstract) makes it easier to
maybe we should apply some code style conventions during maven build...
also ... I personal don't like some *old school* doings like:
private String _foo;
public void setFoo(String foo)
{
_foo = foo;
}
no need for _ ...
I was discussion things like that with Bernd last days.
-Matthias
On
I am with you Matthias ;-) I prefer to use 'this'...
Bruno
On 2/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
maybe we should apply some code style conventions during maven build...
also ... I personal don't like some *old school* doings like:
private String _foo;
public void
I am with you Matthias ;-) I prefer to use 'this'...
expect, you are using vi ... :-))
The current release policy causes headache for Martin and confusion for me. ;-)
Just looked at the tomahawk 1.1.2 branch. It depends on commons 1.1.3-SNAPSHOT.
Shouldn't the tomahawk freeze depend on commons 1.1.2 instead?!
The longer I think about it, the more I'm really sure that the only
I've taken some aspirine, so my headache is better now ;)
regards,
Martin
On 2/17/06, Manfred Geiler [EMAIL PROTECTED] wrote:
The current release policy causes headache for Martin and confusion for me.
;-)
Just looked at the tomahawk 1.1.2 branch. It depends on commons
1.1.3-SNAPSHOT.
Sounds good to me.
+1 for renaming them.
On 2/17/06, Manfred Geiler [EMAIL PROTECTED] wrote:
One thing we could do for our users to make things clearer regarding
the question Does a certain class belong to commons or not?:
Refactor all commons classes from
org.apache.myfaces.*
to
One thing you could do is refactor using IDE so that the impl and
tomahawk stuff are changed automatically. Then revert your entire
commons dir back to the way it was. Then do an svn move for just the
commons stuff (all at once) and then checkout. Then check in the IDE
refactored stuff.
Make
+1
On 2/17/06, Sean Schofield [EMAIL PROTECTED] wrote:
One thing you could do is refactor using IDE so that the impl and
tomahawk stuff are changed automatically. Then revert your entire
commons dir back to the way it was. Then do an svn move for just the
commons stuff (all at once) and
Well it's a package refactoring. So, each dependend (or using) class
in impl and tomahawk must be aligned as well. I'm feeling much warmer
when doing this within my IDE, which has total knowledge of all
dependencies. ;-)
BTW, is everyone really aware of what I'm proposing here?
We have an
On 2/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
I am with you Matthias ;-) I prefer to use 'this'...
expect, you are using vi ... :-))
on a monochrom display...
:-)
Manfred
I work with my Spectrum ZX80, which runs pretty smooth ;-)
On 2/17/06, Manfred Geiler [EMAIL PROTECTED] wrote:
On 2/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
I am with you Matthias ;-) I prefer to use 'this'...
expect, you are using vi ... :-))
on a monochrom display...
The benefits outweight the downsides. Currently, there's no guarantee
that any particular Myfaces release will support your custom
components if you have a dependency on our classes.
Also, up to this point, if you're depending on Myfaces classes for
your custom components, it's difficult to know
+1 to the reorganization.
I too feel this is the only way to release the 'Core' separate from any
components, and that separate releases are vital to all of the MyFaces
projects.
-Original Message-
From: Manfred Geiler [mailto:[EMAIL PROTECTED]
Sent: Friday, February 17, 2006 3:43 AM
Crazy team, they haven't ever test a chinese abacus.. :-D
Bruno Aranda wrote:
I work with my Spectrum ZX80, which runs pretty smooth ;-)
On 2/17/06, Manfred Geiler [EMAIL PROTECTED] wrote:
On 2/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
I am
I didn't have time last night to address the branch fully. We just
need to change some refs on the branch once its made. It was on my
list today. I will check in soon and then tell me what you think.
Sean
On 2/17/06, Martin Marinschek [EMAIL PROTECTED] wrote:
I've taken some aspirine, so my
Cool!
I still have my Sinclair ZX81 in the attic.
Can you give me the right compiler directives?
:-)
Manfred
On 2/17/06, Bruno Aranda [EMAIL PROTECTED] wrote:
I work with my Spectrum ZX80, which runs pretty smooth ;-)
On 2/17/06, Manfred Geiler [EMAIL PROTECTED] wrote:
On 2/17/06, Matthias
[ http://issues.apache.org/jira/browse/MYFACES-864?page=all ]
Matthias Weßendorf resolved MYFACES-864:
Resolution: Fixed
valueChangeNotifier
---
Key: MYFACES-864
URL:
[ http://issues.apache.org/jira/browse/MYFACES-864?page=all ]
Matthias Weßendorf closed MYFACES-864:
--
valueChangeNotifier
---
Key: MYFACES-864
URL: http://issues.apache.org/jira/browse/MYFACES-864
Gerald Müllan (JIRA) schrieb:
Tying InputSuggestAjax to dojo
--
Key: MYFACES-1133
URL: http://issues.apache.org/jira/browse/MYFACES-1133
Project: MyFaces
Type: Improvement
Components: Sandbox
Versions: Nightly
Reporter:
Mike's arguments are valid.
To make it easier for developers out there, it might make sense to exclude
other changes from this minor. That would reduce the problem sources for
those outside developers...
Alexander
-Original Message-
From: Mike Kienenberger [mailto:[EMAIL PROTECTED]
What if we changed the commons version on the trunk to 2.0.0 then to
address the major change issue?
I agree with Mike that users can always slowly refactor their stuff
over time. We have a 1.1.2 release finished for commons so people can
use that until they want to change.
Tomahawk might be a
After talking with Martin and Manfred I've come to realize the issue
here. I now propose the following approach to releasing the core.
This approach also applies to tomoahawk (just replace the word 'core'
with 'tomahawk'.)
1.) branch commons
2.) branch core
3.) increment commons snapshot
+1
Yes, I was going to suggest exactly the same thing!
And at some future point, we'll probably also incorporate a
repackaging step into one of these (I'd suggest core, probably) to
give the two commons versions different namespaces.
On 2/17/06, Sean Schofield [EMAIL PROTECTED] wrote:
After
On 2/17/06, Sean Schofield [EMAIL PROTECTED] wrote:
After talking with Martin and Manfred I've come to realize the issue
here. I now propose the following approach to releasing the core.
This approach also applies to tomoahawk (just replace the word 'core'
with 'tomahawk'.)
1.) branch
And at some future point, we'll probably also incorporate a
repackaging step into one of these (I'd suggest core, probably) to
give the two commons versions different namespaces.
That's what I'm attracted at more and more, too. ;-)
Manfred
And what about the TCK when releasing core, it should go before any
release (commons and core), right? If it fails due to something in
commons we may have to fix commons. Instead of put commons directly to
final I would change it to release candidate and only after TCK is
passed put it final.
MyFaces (sub-)projects on the site:
API
Impl
Commons
Tomahawk
Sandbox
(Tobago)
agreed.
We will release the following assemblies with different release numbers:
Core (= API + Impl)
Commons
technically this is not an assembly. its released as a maven pom and
jar and its in
You meant
4.) increment core snapshot version on the trunk
instead, right?
Right. Sorry about the confusion.
Manfred
Sean
And at some future point, we'll probably also incorporate a
repackaging step into one of these (I'd suggest core, probably) to
give the two commons versions different namespaces.
What do you mean by this?
Sean
Good point about the TCK but I think we should handle that slightly
differently then what you are suggesting.
Why not test the TCK agains the trunk core with the branch commons?
If it passes you release commons. At that point you are not likely to
need to fix anything on the upcoming core
And that's why I still have the opinion that we cannot do other than
release all three at the same time.
Scenario:
1. We release commons-1.1.2 + core 1.1.2 (core 1.1.2 depends on commons-1.1.2)
2. days go by...
3. We release commons-1.1.3 (because there where significant changes)
+ tomahawk
Since this is still sandbox we can do whatever for now. I think we
need to wait a while before officially releasing the ajax stuff. We
want to make sure we all have time to review it and that we're happy
with some of the general solutions needed for most ajax components.
It will be hard to
Interesting scenario but I don't like your conclusion. We want to get
away from forcing a releaase of all three at the same time. That was
a major goal of the maven reorg. We need to try to solve this problem
without always release all three.
Sean
On 2/17/06, Manfred Geiler [EMAIL PROTECTED]
On 2/17/06, Sean Schofield [EMAIL PROTECTED] wrote:
And at some future point, we'll probably also incorporate a
repackaging step into one of these (I'd suggest core, probably) to
give the two commons versions different namespaces.
What do you mean by this?
It's what we've talked about
Maybe releasing commons implies releasing core and also tomahawk, but
releasing tomahawk, for instance, does not imply having to release
commons if there has not been changing in commons.
Commons should have longer release cycles than the other modules,
Bruno
On 2/17/06, Mike Kienenberger [EMAIL
It's probably also worth pointing out before we get too caught up in
the doom and gloom situation of incompatibilities that we need to
start making all commons releases backwards compatible in order for
end-users to depend upon them. That will probably eliminate many of
the issues of
Yes, true.
I should have said: And that's why I still have the opinion that we
cannot do other than
release all three at the same time - as soon as we release a new
commons version.
Thanks for pointing this out, Bruno.
Manfred
On 2/17/06, Bruno Aranda [EMAIL PROTECTED] wrote:
Maybe releasing
I agree, that is one of the reasons why I stopped the discussion
of moving dojo to tomahawk now, we need more time and implementations
and gather feedback to see if all this stuff works.
Werner
Sean Schofield schrieb:
Since this is still sandbox we can do whatever for now. I think we
need to
Gerald, thanks for your efforts, I took a quick glance into it, and for
me it seems like nothing is coming back from the call (havend debugged
into it yet), dojo has not changed since 27/1.
Maybe some ajax triggering mechanism has been disabled which is
responsible to call the backend bean.
Werner,
Can you provide an example of how to specify the items
line for those of us who are javascript-ignorant?
I'd really like to remove the save/cancel buttons since these don't
work well with JSF and just confuse the end-user.
I was hoping that facelets would just pass them through by
Hello Ted and Manfred,
last week I asked the MyFaces community about the incubator sign-off for
Tobago. There were no objections against leaving the incubator.
Therefore I would like to know how to proceed. What are the next steps
on our way to become a MyFaces sub-project?
Best regards
I'm +1 for doing the move in the trunk and at least bumping to 1.2 or
maybe 2.0 as Sean suggested.
I don't like the idea of this change right before a release on the
branch that is going to release at all.
Since the release is imminent I'd also suggest (but that is all it
is) that we
[ http://issues.apache.org/jira/browse/MYFACES-1028?page=all ]
Mario Ivankovits closed MYFACES-1028:
-
Resolution: Invalid
AjaxDecodePhaseListener no longer uses ComponentUtils and thus its bug is no
longer happening
make autoUpdateDataTable
Good point about merging back down. Lets wait until we get both core
and tomahawk out the door then.
Sean
On 2/17/06, Bill Dudney [EMAIL PROTECTED] wrote:
I'm +1 for doing the move in the trunk and at least bumping to 1.2 or
maybe 2.0 as Sean suggested.
I don't like the idea of this change
Hi!
I would like to remove the unused method
tomahawk-sandbox/org.apache.myfaces.custom.util.ComponentUtils.findComponent
its buggy (didnt traverse through facets) and no longer used. So I would
like to get this trap out of line.
Any objections?
Ciao,
Mario
well there are usually 2-3 ways in dojo as far as I could find out
how to pass the dojo params.
First of all the way you described it, but that breaks (x)html validation.
Except for a few components there usually is another way:
here is an excerpt from the docs:
+1
On 2/17/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
I would like to remove the unused method
tomahawk-sandbox/org.apache.myfaces.custom.util.ComponentUtils.findComponent
its buggy (didnt traverse through facets) and no longer used. So I would
like to get this trap out of line.
Some of the state manager code coming in from ADF Faces
will help in this area; it's not a magic bullet, but it can help
significantly.
-- Adam Winer
On 2/17/06, Jesse Alexander (KBSA 21) [EMAIL PROTECTED] wrote:
From my tests comparing client and server state, I must say client-state
will
I find an _ convention extremely useful - when reading
code, it is very helpful to know immediately what is a
method variable and what is an instance variable.
The ADF Faces conventions use _ as a prefix
for anything which is private (instance variables,
methods). Makes it easy to read and
On 2/17/06, Werner Punz [EMAIL PROTECTED] wrote:
But I think you get the idea
You're giving me far too much credit. I don't understand the
difference between what you said here and earlier :)
How does this look on an actual JSF page?
I tried sticking this in the head tags
Since most of the code in myfaces right now also uses the '_' I think
we should stick with it.
Everyone needs to keep in mind that the final code style that we come
up with is not going to be the same as your personal preference or
what Sun says is the right way. There is an overall style to
Sean Schofield schrieb:
+1
done so
---
Mario
Hi All,
I'm personally not in favour of releasing commons at all.
I think the correct solution is to have a build step that automatically
changes the package-name of the commons classes and builds it into the
real project being built.
As an example, when building impl,
Hi Mike I can only give pseudo code here,
first of all, in an actual JSF page I would like to see
code like this
s:richEdit id=editor/
but we cannot have that for now:
if you want to see the rich editor in action in a jsf page and if you
want to pass the parameter as well, use a normal
+1
To me, the sandbox is fair game.
Dennis Byrne
-Original Message-
From: Sean Schofield [mailto:[EMAIL PROTECTED]
Sent: Friday, February 17, 2006 03:13 PM
To: 'MyFaces Development'
Subject: Re: remove unused method
+1
On 2/17/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
I
yeah, take it out. If theres a working version, that it :)On 2/17/06, Dennis Byrne [EMAIL PROTECTED] wrote:
+1To me, the sandbox is fair game.Dennis Byrne-Original Message-
From: Sean Schofield [mailto:[EMAIL PROTECTED]]Sent: Friday, February 17, 2006 03:13 PMTo: 'MyFaces
I meant to say: If there's a working version, that _is_On 2/17/06, Grant Smith [EMAIL PROTECTED]
wrote:yeah, take it out. If theres a working version, that it :)
On 2/17/06, Dennis Byrne [EMAIL PROTECTED]
wrote:
+1To me, the sandbox is fair game.Dennis Byrne-Original Message-
From: Sean
Actually I would love to have such a passthrough
but probably many people here would object it
due to the fact that the dojo tags break html validation.
(I talked with Alex Russel the dojo core maintainer about this and he said,
that in his opinion being lenient towards such things
is good,
Yes lets take a moment to reconsider all of our options.
Sean
On 2/17/06, Simon Kitching [EMAIL PROTECTED] wrote:
Hi All,
I'm personally not in favour of releasing commons at all.
I think the correct solution is to have a build step that automatically
changes the package-name of the commons
Why we should stick with the '_'?
The Apache Code Style is the Sun Code Style without allowing tabs.
MyFaces is the first project that used the '_'. (so far I can see)
The Sun Code Style doesn't allow the '_'.
And I would never accept code without braces.
Sean Schofield schrieb:
Since most of
Wow. So it turns out that Myfaces suffers from a particularly nasty bug which was also present in the Sun 1.1 RI.
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=87
So anyone who is disabling a dropdown, beware of this! Your backing
bean will become null for that property on submit.
Late to the party, but I can show you how to do this better... ;-)
Firstly, there's no need to use invalid markup with Dojo, provided
you're using XHTML. You can use namespaces. Secondly, I have a Dojo
Editor / JSF integration almost working that would let you simply do this:
dj:inputEdit
Wendy is exactly right.Of course, it would be much more convenient if the JSF 1.2 jars were on ibiblio.org to avoid the extra configuration to pick up the
java.net repository.I believe there is work already underway to establish an automatic sync for some of the java.net artifacts to ibiblio.org.
95 matches
Mail list logo
