Sean,
Thanks for your initiative.
My thoughts and visions about the restructuring differ slightly, but
I'm happy to dicuss this.
Apache Faces (aka the JSF umbrella)
==
I personally like the idea of that umbrella project that could grow
to become the home of all JSF
But would this not imply, that stuff underneath the sandbox must
be a component?
What about stuff that should evolve into the implementation (eg. new
non-jsp renderkits) or into the commons (eg. new utility-classes) subprojects?
regards
Alexander
-Original Message- (shortened)
From:
Thanks for your attention, Alex.
Only a typo. Actually I meant Collection instead of Components, so
the correct sentence should be:
I would rather make this a subproject of Collection (see structure below).
Sorry, for the confusion,
-M
On Apr 11, 2005 1:34 PM, Jesse Alexander (KBSA 21)
[EMAIL
I really like the shared classes as a subproject, and I'd actually like to see more things moved in that direction, like the auto-building of ValueBinding-getters through an XML file. I agree that this could put more pressure on our impl. and components classes because there is another API that we
I built and published the 1.0.9 release. Matthias said that we need
to sign with PGP before the official announcement. Can someone help
me out with this? We should probably do this ASAP since the jars are
already available on the myfaces website.
Also at some point we need to discuss mirroring
A couple of general notes:
* Three level hierarchies are not really a good idea,
because the leaf nodes of the tree have a hard time
getting either the attention they want or the oversight
(from the PMC) that they need. I would not do that.
* At the end of the day, anyone you accept as a
Apache Faces (aka the JSF umbrella)
==
I personally like the idea of that umbrella project that could grow
to become the home of all JSF related Apache stuff. But, my proposal
would be to do it right now with the name we already have: Apache
MyFaces Why not let
I'm forwarding Manfred's answer to the list (I assume he meant this
for all of us.)
-- Forwarded message --
From: Manfred Geiler [EMAIL PROTECTED]
Date: Apr 11, 2005 12:48 PM
Subject: Re: Proposal: Modest Restructuring of MyFaces Project
To: Sean Schofield [EMAIL PROTECTED]
On
You'll definitely want to take advantage of the mirrors. I shouldn't have
to explain what impact you'll have if you don't. Onward and upward, let's
face it (pun intended) MyFaces is picking up steam. Everyone on the dev
team (committers) should be versed in how to branch and release
Comments interspersed.
On Apr 11, 2005 11:00 AM, Sean Schofield [EMAIL PROTECTED] wrote:
I'm forwarding Manfred's answer to the list (I assume he meant this
for all of us.)
-- Forwarded message --
From: Manfred Geiler [EMAIL PROTECTED]
Date: Apr 11, 2005 12:48 PM
What is wrong with doing a component-binding and setting this stuff up in your bean?
We've had a few cases where the datatable's columns cannot be defined inside the JSP and this has worked just fine for us.
On Apr 11, 2005 1:06 PM, Sean Schofield [EMAIL PROTECTED] wrote:
We're trying to use
How would this work exactly? Would the backing bean add column
children to the data table as needed? I suppose that could work but
it seems like a roundabout way of doing it. Plus what if I want to
render the data differently in the columns depending on their type
(similar to tree2?) That
Yes, we basically just did it programmatically inside our bean. I agree with you that rendering rules should be separate from the application logic, but that doesn't mean it HAS to reside in the JSP.
Could you maybe give a JSP example?
On Apr 11, 2005 1:28 PM, Sean Schofield [EMAIL PROTECTED]
On Apr 11, 2005 11:24 AM, Sean Schofield [EMAIL PROTECTED] wrote:
I can see the intent, but commons also implies (at least from my
Jakarta Commons biased viewpoint :-) that the stuff here is generally
reusable, completely separate from MyFaces, and that doesn't seem
likely for what we've
On Apr 11, 2005 11:40 AM, Heath Borders [EMAIL PROTECTED] wrote:
Ideally all API jars should be exactly compatible (down to protected
methods), so that it shouldn't matter if someone uses a Sun API with a
MyFaces impl.
For the record, as specifically related to the method and variable
But I thought that you were proposing changing the component (and I'm guessing the Tag as well), and I'm just wondering if you could provide an example of your changes in a JSP form.
On Apr 11, 2005 1:48 PM, Sean Schofield [EMAIL PROTECTED] wrote:
I didn't say that that this functionality *had* to
I agree with the same project concept although, from a technical
point of view, *all* the source code for MyFaces is in the same
project -- it's really about directory structure within the
repository. For that, it's still likely to be convenient to have the
api and impl classes in two
On Apr 11, 2005 12:12 PM, Sean Schofield [EMAIL PROTECTED] wrote:
[snip]
This follows an architectural principle that has been done with all
the recent Java APIs, especially the ones that are going in to J2EE at
some point. Indeed, that's going to become an issue for MyFaces with
JSF
We are trying to do something like this in Shale. The proposed plugin is
called Clay. The basic idea is to allow defining a subtree of components using
something other than the JSP tags.
We currently have three subtree composition options:
1) Define in XML only
2) Define at runtime with a
I'll try and get an example to you shortly. BTW I thought of an
additional drawback to the approach you suggested. Suppose you have
fifteen columns that you need to render but you need to render them
the same for each column.
This is the opposite of my earlier example where you need to
Gary,
I've seen this proposal on the struts-dev list. I haven't really had
time to delve into it yet but in this case it seems to be solving the
wrong tree. While it might be appropriate to programatically add
components to the tree in some cases, it does not make sense in this
case.
I have
I will fix the build script so that it publishes the release jar files
to http://www.apache.org/dist/. According to the ASF instructions its
ok to have nightlies and the release candidates in the cvs.apache.org
location so we'll keep the procedure the same for those.
We will stlll need a release
Vote result on releasing 1.0.9:
(6) +1 votes
(0) -1 votes
(0) 0 votes
On Apr 8, 2005 10:35 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
no :)
ok, here is my +1
On Apr 8, 2005 4:04 PM, Sean Schofield [EMAIL PROTECTED] wrote:
No but that is one of the trivial changes we made after
23 matches
Mail list logo
