Right. See a very recent discussion with Bruno and I regarding that.
BTW, who is the expert on that? Stan?
sean
On 6/21/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> Wait a minute: WML is nothing that should be in tools, right?
>
> WML is the renderkit, isn't it?
>
> regards,
>
> Marti
Wait a minute: WML is nothing that should be in tools, right?
WML is the renderkit, isn't it?
regards,
Martin
On 6/21/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> OK what if we create a root level dir called "tools"? So we have:
>
> tools/codegen
> tools/xdoclet
> tools/wml
>
> With the c
Looks great...
regards,
Martin
On 6/21/05, Bruno Aranda <[EMAIL PROTECTED]> wrote:
> Cool! This will make the project lighter and easier to maintain. I've
> seen that there is a timestamp check so you will donwload the jar only
> if necessary. I think this is an good proposal,
>
> Regards,
>
>
Good idea: +1
We have a bunch of improvements that we have been putting off until
the reorg. Add this to the list ;-)
On 6/21/05, Bruno Aranda <[EMAIL PROTECTED]> wrote:
> After the reorganization, I think that it would be very useful the
> possibility to generate example wars using the jsf re
After the reorganization, I think that it would be very useful the
possibility to generate example wars using the jsf reference
implementation jars and the myfaces-extensions jar, as many users are
having problems of compatibility. We could use the build file to
generate this specific wars in order
Cool! This will make the project lighter and easier to maintain. I've
seen that there is a timestamp check so you will donwload the jar only
if necessary. I think this is an good proposal,
Regards,
Bruno
2005/6/21, Sean Schofield <[EMAIL PROTECTED]>:
> First off, thanks to James Mitchell (of the
[ http://issues.apache.org/jira/browse/MYFACES-281?page=all ]
sean schofield closed MYFACES-281:
--
Fix Version: Nightly Build
Resolution: Fixed
Thanks Brendan for the bug report and fix suggestion.
> myfaces-ext.tld definition for tree2 has id
First off, thanks to James Mitchell (of the Struts team) who has been
teaching me the wonders of svn:externals. I hope my SVN reorg will
make him proud. :-)
While James and I were discussing the Struts layout he also mentioned
something interesting. They no longer keep any jar files in their
re
Thanks for the feedback. I skipped the codegen stuff for the initial
pass. We can (and will) deal with it eventually. Some of it appears
to be necessary for the WAP stuff (which belongs in tomahawk) so I
have to think on that a bit.
sean
On 6/21/05, Bruno Aranda <[EMAIL PROTECTED]> wrote:
> Im
Impressive. Thanks Sean for taking the time and neuron processing time
to reorganize the SVN. I've just done a checkout of the current
without problems. At first sight, it looks very clear and intuitive.
This is, indeed, a more natural organization of the project. The
svn:externals system is really
[ http://issues.apache.org/jira/browse/MYFACES-285?page=all ]
sean schofield closed MYFACES-285:
--
Resolution: Cannot Reproduce
Closing this issue based on Bruno's findings.
> selectOneMenu throwing wrong conversion error
>
[
http://issues.apache.org/jira/browse/MYFACES-285?page=comments#action_12314172
]
Bruno Aranda commented on MYFACES-285:
--
I've tried to reproduce this issue with the latest SVN and I haven't found any
bug. Everything works as expected. The value is a
OK I am a little late to this thread as I have two weeks of emails
(for work and open source) to catch up on. Please be patient with me
if this has already been mentioned ...
Just wanted to make sure that everyone was aware that you can use
forceId and forceIdIndex together to get ids like foo[0]
[
http://issues.apache.org/jira/browse/MYFACES-287?page=comments#action_12314169
]
Bruno Aranda commented on MYFACES-287:
--
Which section of the spec says that? AFAIK, you are wrong as the only
attributes that can have a column are those of a UICompone
I finished up a test run of the reorg. There are several outstanding
issues (no lib directory etc.) but there is enough there for you to
get the picture.
You can browse it at: http://svn.apache.org/repos/test/myfaces/
To get the latest do a checkout of:
http://svn.apache.org/repos/test/myfaces/c
Korhonen, Kalle wrote:
For MyFaces unit testing, just throwing out the idea for others to think
about.
I think this is a great idea, Kalle.
+1
Kalle
Kalle,
Interesting idea about unit tests as inner classes. At times I have
been frustrated by lack of access to private fields ... I'll have to
think about that one.
As for MyFaces, there appears to be some limited unit test stuff but
not much. My guess is that the existing stuff will ultimate
Hi Martin,
I'm planning on sending out an email to the user list later this week (I'm
currently moving to a new house) so that people can join us for a beer after
the dinner. The room (for the dinner) only takes 20 people and we are already
fully booked, which is good. Marc can join us if he wa
First, thanks Sean for doing the heavy lifting. Restructuring the whole
codebase is always more cumbersome than it should and you always end up
breaking some little pieces. But, it's needed and it's always better to
do it as soon as possible. Ignore people who'll ask "why do we need this
again?" :)
OK what if we create a root level dir called "tools"? So we have:
tools/codegen
tools/xdoclet
tools/wml
With the codegen, xdoclet and wml directories the same as what's under
src in the current structure now.
I can rearrange like this and then we can eventually clean up the
build scripts so tha
I'd like to start doing the SVN reorg this Thursday. I propose that
on Thursday AM, Manfred temporarily disable SVN commit access to all
but Manfred and myself. I'll also request that SVN emails be turned
off temporarily while we move things. I'll then do the SVN reorg on
Thursday and we can rea
Hey Manfred,
On 6/21/05, Manfred Geiler <[EMAIL PROTECTED]> wrote:
> What do you mean by "preserveDataModel is too aggressive"?
I agreed with Kalle's statement that storing the whole data model
would be too much. Now it is clear that only the visible information
is preserved. :-)
However, it do
I've talked with Jurgen and I will be escorting him through this process,
Regards,
Bruno
2005/6/21, Bruno Aranda <[EMAIL PROTECTED]>:
> Well, I am going to get in touch with Jurgen to proceed immediately
> ;-) and I'll tell you,
>
> Regards,
>
> Bruno
>
> 2005/6/21, Martin Marinschek <[EMAIL
No worry, I didn't got you wrong.
I'll try to get you the example asap, but I might require some times, as I can't play with that on my production system. So I'll have to go through the code.
I agree that we should make thing as simple as possible.
I think there are good reasons to provide t
Yes, right. It's not needed to compile.
But it is still usable as convenient tool for new components *and* it
is still needed to (indirectly) change code that is embedded in those
"do not change generated code" sections.
-Manfred
2005/6/21, Sean Schofield <[EMAIL PROTECTED]>:
> Its not currently
Its not currently needed to build the source right? My understanding
was that it was used by Manfred and others back in the day when they
were creating the source code. So its not needed to compile right?
Let me take a look at where this would go in the svn reorg ... (I
agree that as far as art
DataTable: Facets Bug
-
Key: MYFACES-288
URL: http://issues.apache.org/jira/browse/MYFACES-288
Project: MyFaces
Type: Bug
Versions: 1.0.9 beta
Reporter: Mathias Werlitz
Priority: Blocker
There seems to be a big bug in the dataTab
Don't get me wrong. I'm not against the new id proposal(s) a priori.
What I would like to make sure first: Is there really no other way
then to bother the user (when I say user I mean the JSF user i.e.
developer that uses JSF, not the end user!) with such implementation
issues? My understanding of
Hello Manfred,
I'll try to find a good explanation why it doesn't solve the concurrency problem.
The only explanation I have right now is that it's the first thing I tried, and it didn't fix the problem (it was even worse, but I don't know why yet).
Another issue is the need to have a seriali
Cannot fully agree:
I'm sure preserveDataModel *does* avoid concurrency problems, because
all phases prior to re-rendering see the old unchanged row set. Only
after all pre-render phases (model update, application actions, ..)
have ended, the table data is refreshed from the backing bean i.e.
from
I agree with Manfred that preserveDataModel is quite efficient in it's implementation.
But it doesn't solve the same kind of problem.
preserveDataModel allows you to keep user modifications between requests.
rowId would allow you to avoid concurrency problems as just using the preserveDataModel
Of course yes, I didn't mean in the binary release, but in the source
release, sorry...
regards,
Martin
On 6/21/05, Bruno Aranda <[EMAIL PROTECTED]> wrote:
> I do also think that this code generation stuff should not be included
> in the binary release. I think it is only used by developers who
I do also think that this code generation stuff should not be included
in the binary release. I think it is only used by developers who
create components, so they already have the sources. And, moreover,
the build.xml is always used, and it comes with the source, so
shipping the codegen stuff with
Well, I am going to get in touch with Jurgen to proceed immediately
;-) and I'll tell you,
Regards,
Bruno
2005/6/21, Martin Marinschek <[EMAIL PROTECTED]>:
> Wuff!
>
> we want those ;)
>
> whatever you do, get them in the codebase fast...
>
> I also want Werner's AJAX inputText component, I h
What do you mean by "preserveDataModel is too aggressive"?
It was introduced to exactly solve this common problem. Fact is, we
want UI components that behave as simple as fat client components
(Swing) do. What we expect is, that when an action is fired, a table
must not be changed in the meantime (
I agree that the email variable should be available only inside the dataTable, and this is what I suggest.
The _expression_ would be stored and then evaluated only at the row level, where the email variable is set. It would be quite meaningless to evaluate the rowId in a higher scope, as the "v
Thanks Martin,
perfect explanation.
(These classes where perpetrated by me and are undocumented at all -
shame on me)
I am not sure if we really should ship this stuff with binary release,
because it only makes sense for experienced component developers. So
shipping it together with source should
Wrong declaration of column tag in myfaces_html.tld
---
Key: MYFACES-287
URL: http://issues.apache.org/jira/browse/MYFACES-287
Project: MyFaces
Type: Bug
Versions: 1.0.9 beta
Environment: Linux/JBoss
Report
Hi,
I'm not sure if this is the right mail list to post this issue,
but since I got no replies from the myfaces-user list, I wonder if any
developer has worked with the Sun JSF RI + myfaces-extensions. Please
note that I'm not asking about how to use it, but to confirm that this
works. That wa
39 matches
Mail list logo
