Hello,
I'm experimenting with Trinidad dialog framework, return events and etc.
It works very well except one jsp. That jsp is nothing special but
return event is never delivered.
With debugging I found following:
1) Dialog is correctly started and open new window.
2) In new window user can
On 8/14/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hello,
Compilation of current Trinidad version fails because of tearDown and
setUp method overriding. Should I look into it or another patch for test
classes is already on the way?
I checked in a patch for this on Saturday, and it
On 8/7/06, Adam Winer [EMAIL PROTECTED] wrote:
Ideally, we'd get rid of any specific do you support PPR
and replace it with things that are less Trinidad-specific,
like Do you support XMLHttp? I'd be very happy to see
those sorts of things made public.
Wouldn't this mean that the developer
The spec - http://www.w3.org/TR/CSS21/syndata.html#value-def-uri -
seems clear that url() is required (though quotes are not required).
I'd favor an option #3:
- Convert url(); anything other than than this syntax gets dropped
and logged with a warning
But we should talk about the manner of
Ah, looks like it is done. Could you do two things?
- Close the issue with this solution
- Start a skinning how-to Wiki page, also including this solution?
Thanks!
This reminds me: I need to check internally (at Oracle) whether some
of the other ideas we had for changing up output to improve
+1 for option #3. I also like the 4 rules, so +1 for those as well.
Simon Lessard
Fujitsu Consulting
Adam Winer [EMAIL PROTECTED]
2006-08-14 12:01
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject:Re: [Proposal] Skin:
Sure!
Simon Lessard
Fujitsu Consulting
Adam Winer [EMAIL PROTECTED]
2006-08-14 12:05
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject:Re: ADFFACES-85
Ah, looks like it is done. Could you do two things?
- Close the
Currently we have the internal capability:
-adfinternal-partialRendering
How about we replaces these with three public capability:
xmlhttp (true/false)
iframes (true/false)
trinidad-partialRendering (true/false)
One thing about naming--it seems the capabilities use an odd mix of
dashes and
On 8/14/06, Adam Winer [EMAIL PROTECTED] wrote:
Is the latest Shale code out on the snapshot repository?
Yes, in the Apache snapshot repository (version 1.0.3-SNAPSHOT is updated by
the nightly builds).
-- Adam
Craig
On 8/14/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 8/14/06,
It worked for me.
kill your org.apache.shale folder in the m2_repo
the correct JAR is public
On 8/14/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 8/14/06, Adam Winer [EMAIL PROTECTED] wrote:
Is the latest Shale code out on the snapshot repository?
Yes, in the Apache snapshot
Killing shale directory did the trick for me.
Thanks,
Simon Lessard
Fujitsu Consulting
Matthias Wessendorf [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
2006-08-14 15:22
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject:
yeah,
I am not sure why you have to do that. In my old company we had
lot's of issues with that (maven1). So, if something *should* be different...
I kill something in the repo ...
On 8/14/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Killing shale directory did the trick for me.
Thanks,
My understanding is that:
- Maven 1 checked for newer versions of snapshots every build.
- Maven 2 checks, by default, once a day, but can be forced
to check explicitly (I don't know how, though).
There's a -U option on Maven 2 to forcibly download new
versions, but that applies to *everything*
Hey all,
For some of our internal, non-open source work here at Oracle,
we're heavily depending on Trinidad (yay!). The catch is that,
at certain points, we need a stable branch to build off of and
apply only limited bug fixes so that internal work never gets
destabilized.
What I'd like to do
I think basicly that what you want is something like:
a branch for a release or a rc, which is also maintained.
I think that's fine with Apache, why not?
In MyFaces we do a branch for *each* release too, but we are
not maintaining the branches *after* the release (which is bad).
So the work
In general, yes, we just have a public branch for a
release which continues to be maintained, which
is a good thing.
My concern is that, in this case, the one calling
for the branch is not the Trinidad/MyFaces community,
but a specific company. Ideally, the two match up
and agree, in which case
basicly I think this discussion is out of scope
for this community. It's more a *general* thing.
Currently there are some more donations by companies
(like XFire from Iona). I am not sure how they deal with that.
When they (Iona or sb. else) needs a special branch.
I am also not sure, what
I am also not sure, what Mergere does, when they want something special?
I am refering to the maven development.
Maybe should post this on the [EMAIL PROTECTED] list ?
On 8/14/06, Adam Winer [EMAIL PROTECTED] wrote:
In general, yes, we just have a public branch for a
release which
ok, I got no negative feedback (or positve) on that,
so I think you all ok with the m1-plugins to be released.
(in a negative case, I bet sb. would had said something)
We also discussed that the Java5 thing is not that important.
here is my +1 for this RC of the plugins.
-Matthias
On 8/4/06,
On 8/14/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 8/14/06, Adam Winer [EMAIL PROTECTED] wrote:
Hey all,
For some of our internal, non-open source work here at Oracle,
we're heavily depending on Trinidad (yay!). The catch is that,
at certain points, we need a stable branch to
On 8/14/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 8/14/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 8/14/06, Adam Winer [EMAIL PROTECTED] wrote:
Hey all,
For some of our internal, non-open source work here at Oracle,
we're heavily depending on Trinidad (yay!). The catch
Hi,
this email contains two things.
a) Call for help on documentation:
If you like to provide some documentation about the Trinidad plugins,
feel free to add content to the wiki. Or provide xdoc or apt patches
;)
b) Structure:
There are two options for handling the doc structure:
1. create a
b) Structure:
There are two options for handling the doc structure:
1. create a site module, which contains *all* documentation
2. having each (sub)project/plugin having it's own src/site and *compose* it.
Shale uses the first (for instance). See [1] for David Geary's remote
example. MyFaces
The simplest answer is to come up with something that is
not company-specific, so it doesn't get Apache into non-profit
legal trouble, yet addresses these real needs. How about
a basic monthly stabilization branch that anyone can pull
off of, and has no particular tie to any one company? And
a
On 8/14/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
this email contains two things.
a) Call for help on documentation:
If you like to provide some documentation about the Trinidad plugins,
feel free to add content to the wiki. Or provide xdoc or apt patches
;)
b) Structure:
There
On 8/14/06, Adam Winer [EMAIL PROTECTED] wrote:
On 8/14/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 8/14/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 8/14/06, Adam Winer [EMAIL PROTECTED] wrote:
Hey all,
For some of our internal, non-open source work here at
b) Structure:
There are two options for handling the doc structure:
1. create a site module, which contains *all* documentation
2. having each (sub)project/plugin having it's own src/site and *compose* it.
Shale uses the first (for instance). See [1] for David Geary's remote
example.
27 matches
Mail list logo
