No, that was already reported. That name stays. Also like af| for
the skinning stays.
Look under some meta-inf folders. /adf/ folder is in there too. the
ResourceServlet path in the web.xml uses also adf.
That's not a bug, I'd say. We just keep it, for now.
-Matthias
On 8/4/06, [EMAIL
This core library could then be called trinidad-core or better
trinidad-shared and would include the skinning features that i wanted to
extract in its own library, among other services that you enumerated. I
guess MyFaces would probably end up using at least some of those shared
services, besides
Ok, i might be jumping to another subject here, but how about modeling the
trinidad selectors into objects?
If i understood correctly, the syntax is something like the following:
Hello,
I was wondering, shouldn't we clear all references to ui and uinode before
creating a RC? I know people should not use trinidadinternal anyway, but I
would prefer to not have to flag something deprecated with the first
release and bestuck with it forever.
Regards,
Simon Lessard
I created a branch for the plugins first.
I'd like to see a first milestone for trinidad core *before* we
start on the big faces-major task. That is a huge change; we should
provide a second release after that.
Just my $0.02.
-Matthias
On 8/4/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
There is another issue regarding the plugins - ADFFACES-112.
I am +1 on patching it on the branch first, and moving then to trunk.
What do you guys think?
-Matthias
[1] http://issues.apache.org/jira/browse/ADFFACES-112
On 8/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
I created a
Hi,
I'm slowly checking the inputDate component and chooseDate component.
Mostly trying to add a startTime attribute that allows the first date
selected to be something else than the current day OR the minimumTime /
maximumTime if the current day isn't in range with those previous two.
for
BTW, I should clarify: when Matthias says af| stays
/adf stays, he doesn't mean for good. These just aren't
in our first pass of renames.
-- Adam
On 8/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
No, that was already reported. That name stays. Also like af| for
the skinning stays.
RequestContext is an important part of it, yeah, but
Skin and SkinFactory (which aren't yet fully public,
but probably need to be) too, probably other stuff.
-- Adam
On 8/4/06, Catalin Kormos [EMAIL PROTECTED] wrote:
This core library could then be called trinidad-core or better
Thanks for fixing my broken english! :)
That's what in my mind, but not written.
They stay first.
-Matthias
On 8/4/06, Adam Winer [EMAIL PROTECTED] wrote:
BTW, I should clarify: when Matthias says af| stays
/adf stays, he doesn't mean for good. These just aren't
in our first pass of
Getting rid of ui and uinode will take a lng time.
It's not even necessary that we do it before getting
out of the incubator. Anything that's in trinidadinternal,
we're not stuck with it, 'cause it's explicitly something that
we can change or delete at any time.
-- Adam
On 8/4/06,
+1 for the later
On 8/4/06, Adam Winer [EMAIL PROTECTED] wrote:
Question:
Are we better off with the current structure:
trunk/plugins
/trinidad
branches/
or with:
plugins/trunk
/branches
trinidad/trunk
/branches
I think the latter is more natural if the plugins
***
I think something like incubator-milestone-1? The code right
now is neither alpha nor production.
I changed them on the branch to
incubator-m1-SNAPSHOT
I'll update the trunk to
incubator-m2-SNAPSHOT
after! the m1 is released and! we *restructured* the
svn layout
-Matthias
-- Adam
hi folks,
I updated a *raw* version of a snapshot, that might endup as our first
rc1 for the plugins. Before we can release this software, we need to
fit into the Apache rules for a release.
-signing
-readme
-documentation/website
-etc
I'll write wiki page for that later, or next week. I ask
14 matches
Mail list logo
