Totally agree with that... We have a lot of traffic on these lists and
it would be easy for messages to get lost without the subject marker...
Adam Winer wrote:
I'm also reluctant to spin us off into a separate e-mail list.
I do think we'll want a [Trinidad] convention for posts though.
--
Khaled,
Much work has been done on Trinidad in a portal environment but we are
not there yet. Trinidad is a very complex renderkit with a lot of
functionality and the existing bridges are deficient to varying
degrees. Currently Trinidad will run in a Proof of Concept using the
Oracle
I agree with Blake. We'll get ourselves into trouble is we begin
switching objects around, because if people need the other access
methods they'll do a cast and we'll break them.
Furthermore, if we use the generic Collections (like List, Set, etc.)
then it is more clear as to what
Also Ven,
That error, although it should never show up if everything is configured
correctly, should not really effect things that badly. It it logged
when something like the resource servlet tries to disable the
configurators after a FacesContext has already been obtained. All it
means is
Well the community seems to have spoken. I've just had the benefit of
dealing with a niche set of usecases and it helped to be able to track
down the original developer of some of the code because they no longer
monitor the lists. The snv blame tool (in ASF) pretty much tells you
who
I don't know why we couldn't have a skin repository on Trinidad
personally. If for nothing else but to provide examples to help people
skin the product.
Scott
Simon Lessard wrote:
Hmm I don't know. I would have liked to see it hosted as a new Trinidad
project, a bit like trinidad-demo so
their feedback, since I'm
not that familiar with what you are doing here..
Thanks,
- Jeanne
Scott O'Bryan wrote:
Can someone please take a look at the patches for the following JIRA
issues and give me your feedback so that we can get these merged
into the JSF 1.2 branch and trunk?
ADFFACES-374
in 1.1 or when running outside of a Portal environment
in 1.2. As for the RenderingContext, I didn't mess with any of this
code as part of either of these patches.
So it doesn't seem like the issues are related to me.
Scott
Scott O'Bryan wrote:
Jeanne,
You're not using this in a Portal POC
, and it does not navigate
Does anyone know what the problem is? I doubled checked to make sure I
had output-modeportlet commented out in trinidad-config.xml.
Thanks,
- Jeanne
Scott O'Bryan wrote:
Can someone please take a look at the patches for the following JIRA
issues and give me your feedback
to
trunk?
Thanks,
Scott
Jeanne Waldman wrote:
No, I'm not running in a Portal.
I'll look into it some. If anyone else sees this issue, let me know.
Jeanne
Scott O'Bryan wrote:
The reason I ask is that I was getting a similar error (to the
StateFieldMarker markup) when using the 1.2 branch
Oh cool, thanks Jeanne. Unlike the 1.2 branch, the patch should apply
cleanly to the trunk. Adam did all the hard work. :)
Scott
Jeanne Waldman wrote:
I did a clean build and it works fine now. Something must have gotten
corrupted.
I'll apply your 379 to trunk.
- Jeanne
Scott O'Bryan
Can someone please take a look at the patches for the following JIRA
issues and give me your feedback so that we can get these merged into
the JSF 1.2 branch and trunk?
ADFFACES-374
ADFFACES-379
Thanks.
Scott O'Bryan
Every once in a great while I make a good suggestion. :) They are few
and far between, but.
Scott
Mark Robinson wrote:
Adam,
I've got all the images I need packaged up in my JAR file. So you can
remove the images from Trinidad. I can change the name fairly
easily. I think
Yeah sorry, I didn't notice the comment either. I updates the JIRA
ticket. You're correct Adam, and I need some advice on the ticket if
you could.
Jeanne Waldman wrote:
Adam,
I just noticed this email. I'll ping Scott.
- Jeanne
Adam Winer wrote:
Has this change been tested? I'm far from
I liked the comment. My portal changes should be commented as some
portal changes. :)
Matthias Wessendorf wrote:
usually I do, not here.however no bug involved.
clean up and enhancements:
I changed some code on sending down the customized messageDetailXxxx.
I also provided a hook for a
No, it's not just backwards compatibility; the point
is that it is perfectly acceptable for a developer to write
a servlet filter. Just because you or I may want to
require portlet support doesn't mean everyone does,
or that everyone on the planet should stop using servlet
filters. So, we
Hey Adam,
In your last checkin to my branch you made some comments I would like to
address. In the DispatchResponseConfiguratorImpl there is an
isApplied function. You were asking why it was there.
The reason for this is simple.. Backward compatibility. You mentioned
to me in some
invoke whatever it is that we come up with.
-- Adam
On 12/22/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
Adam,
You I must have a different definition of robust. Two of the MANY
examples that illustrate my point is as follows:
1. There is no error checking on disableConfiguratorServices
Configurators.
I think this'd also eliminate any need for isInitialized() - put
the onus on the code that retrieves (and therefore might
create) the instance.
-- Adam
On 12/19/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
Adam,
EVERYTHING will have to cast to it, since the entry point does
possible I've broken something in portlet land - I only tested
the changes in a servlet environment.)
On 12/21/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
Adding getInstance() to the configurator will either force us to cast in
a bunch of different places
No, it doesn't. No casts were required at all
services are designed to be run at the beginning and end of
the physical request. The global configurator handles this scenario
but the Javadocs are writtern from an implementors standpoint.
Do you want me to submit a patch to fix the Javadocs or do you want to
do it?
Scott
Scott O'Bryan
The global configurator already treats the render and action request as
a single entity. The real question comes in about what happens during
subsequent render requests. Sometimes, like storing render attributes,
you want the request attributes to hang around for an action request and
each
I'm still wondering why we should bloat the API of every configurator.
And not ALL of the methods I'm looking at adding here can be static.
Scott
Adam Winer wrote:
That method could easily be a static method on Configurator
in my scheme.
-- Adam
On 12/15/06, Scott O'Bryan [EMAIL PROTECTED
I personally like the latter.. Unfortunately very few things can be
developed in a Vacuume. At the very least it should have it's own copy
of impl.
Scott
Matthias Wessendorf wrote:
Looks like all here have already agreed on that one.
What do you have in mind?
a *separate* project with
It's API bloat and I'm also going to have to store some extra privates
on some of these classes as well as expose some additional api's to
support this. I ran into another issue with not implementing the Global
configurator. Take a look at this code.
When used inside of
Adam Winer wrote:
Scott,
My big concern is with the sheer quantity of new public APIs
(that is, public classes in trinidad-api). We should be avoiding making
anything public unless it is absolutely, critically necessary.
Configurator APIs: I'm not completely sold on the name, but anyway,
I
information on the license yet?
Thx,
Matthias
Thanks,
Scott O'Bryan
that ExternalContextUtils
cannot be put into the impl package. It's mostly used for setup of the
RequestContext and some other logic which happens outside of the Faces
scope. So good call.
Scott
Scott O'Bryan wrote:
All of the classes in webapp/wrappers and context/external:
- Why aren't these in impl?
- I
if we run into scoping issues with the two part
portal request.
See, I'm already going to need it.
Scott
Scott O'Bryan wrote:
Hey Adam,
First off, thanks for responding. Your suggestions have been
invaluable. :) Now...
Adam Winer wrote:
So I guess basically I'm making one last appeal
Hey Adam,
First off, thanks for responding. Your suggestions have been
invaluable. :) Now...
Adam Winer wrote:
So I guess basically I'm making one last appeal on the
GlobalConfigurator thing. If you still want it removed I'll get rid of
it. But I honestly think we're backing ourselves
I use eclipse with the four projects and it works just fine. I do have
a suggestion though:
1. Turn off automatic compile - eclipse has trouble removing the target
directories sometimes because the targets are referred to in the project
as source. Comes from the automatic generation of the
Right, but high risk projects could be committed to the sandbox first
and allow them to ferment a bit without effecting the main line. I like it!
+1 (non-binding)
Adam Winer wrote:
On 12/14/06, Danny Robinson [EMAIL PROTECTED] wrote:
+1 (non binding).
Q1 - Would this add more workload to
Expert Group and have tried to
incorporate a design which will allow us to use that spec once it's
finished. The design is still in the preliminary stages, so there is no
official support just yet, but I hope to have that support soon after
the release of the final draft.
Thanks,
Scott
Hello everyone,
I'm looking at supporting launch parameters for the Portal in
Trinidad. To recap my understanding of them, in the TrinidadFilter,
Trinidad does its filter stuff and then does a doFilter on the
FilterChain. When the chain returns, the TrinidadFilter checks for the
existence
), and they won't all fit in a GET.
-- Adam
On 12/13/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
Hello everyone,
I'm looking at supporting launch parameters for the Portal in
Trinidad. To recap my understanding of them, in the TrinidadFilter,
Trinidad does its filter stuff and then does a doFilter
One more question then. Does this run two different lifecycles (ie. the
dialog one runs and returns, then the base one is executed) or is there
a possibility of cramming these into one lifecycle call?
Scott
Scott O'Bryan wrote:
Interesting. I see your point.
Adam Winer wrote
Well in that case... +1 :)
Matthias Wessendorf wrote:
feedback by all is welcome.
a good community provides good code;
that's Apache ;)
-M
On 12/8/06, Böhringer Jochen [EMAIL PROTECTED] wrote:
I'm not a commiter, but I would also raise my hand for the
:: syntax.
Regards
Jochen
Von:
Mark,
Yes, he means trinidadinternal.ui. The reason we are getting rid of
this is basically a historical reason. These classes are basically a
set of adapters designed to port Oracle's old UIX component base over to
Faces. As the components were enhanced and expanded, we started turning
Hey all,
I noticed in the Trinidad tag lib documentation that an af:region tag is
supported. Yet on my relatively new version of the build, the region
tag does not show up in the TLD. Anyone know if Regions are supported
or not? If so, what tld do I need to import to get the tag
. Is that not correct?
Scott
Matt Cooper wrote:
If the link's destination starts with # then yes; if the destination
doesn't start with http://;, https://;, mailto:;, javascript: or
anything else.
On 11/29/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
So they will basically reference bookmarks
Thanks Adam. That's what I was looking for. :)
Scott
Adam Winer wrote:
Guys, this is ALWAYS a # URL. It's the name attr of a link, and
can't possibly be anything more. There are zero portal implications.
-- Adam
On 11/29/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
Right. Well it's
Yay.. Thanks Martin.
Martin Marinschek wrote:
There is nothing offending in copying any of the classes over from
MyFaces-Impl to Trinidad!
regards,
Martin
On 11/8/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
Hey Guys,
All arguments about the need for a common code package aside (yes, I
Hey Guys,
All arguments about the need for a common code package aside (yes, I
will continue to champion this), Trinidad has the need to create
container abstractions for some of our initialization services. We're
basically going to use the external context to pass into these services
Oh yeah, and I'm moving wrapping of servlet objects out of the filters
and into the ExternalContext. That does not mean we can't wrap them in
filters as well, but everytime we do, those filters will not run in a
portal.
Scott
Scott O'Bryan wrote:
Two questions then:
1) Being
abstractions much easier and eliminates the need for special handling of
the Portal usecases.
-- Adam
Scott
Adam Winer wrote:
On 10/20/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
My question is
this, is there any reason we can't provide our own custom lifecycle
object that decorates
/portalserver/reference/techart/asynch_rendering.html
http://blogs.sun.com/gregz/entry/ajaxportlet_updates#comments
http://developers.sun.com/prodtech/portalserver/reference/techart/ajax-portlets.html
Arash Rajaeeyan
On 10/23/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
We discussed
bother with
the *regular* Lifecycle's PhaseListeners.
Thanks,
Matthias
On 10/22/06, Adam Winer [EMAIL PROTECTED] wrote:
On 10/20/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
My question is
this, is there any reason we can't provide our own custom lifecycle
object that decorates the default one
Hey everyone,
I'm going to be starting the portlet work on this starting next week.
Yes, they are actually paying me to fix this stuff :)... So I was
going over some of my strategies for doing some of this work. One of
the major problems with using Trinidad with a portal environment are
, is there any one from Myfaces ?
I have requested to become a member, but I am not sure if they
accept
me!
On 10/11/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
I don't think we really have one yet. I can jump on that if you
guys
want. Michael Freedman is the Spec Lead and he is someone I work
Unfortunately I don't know the release date. Should be available fairly
soon I would imagine. I can try to check for you. I ALSO believe that
it'll run in 1.4 and 1.5. I know the system is built in 1.4 anyway, but
oracle QA's generally test it in 1.5.
Don't get me wrong, I don't want to
, Scott O'Bryan [EMAIL PROTECTED] wrote:
Is there a place where we could store public API's that are not part of
Faces in MyFaces? Would this be the shared-impl package? We'll likely
need to support an interface to handle some of our filter
functionality from a portlet. This interface would need
I don't think we really have one yet. I can jump on that if you guys
want. Michael Freedman is the Spec Lead and he is someone I work with
on a regular basis.
Scott
Arash Rajaeeyan wrote:
hello
who is in charge for JSR 301 here?
--
Arash Rajaeeyan
Correct. I mean it's crappy that we have to go through like 20 layers
of wrappers to make this thing work right. I imagine, though, that it's
going to be that way until the next Portlet Spec. Same way with Ajax.
The new Portlet spec is going to have a request type specifically for Ajax.
not support. Would you guys consider a branch that supports this +
JSF 1.1. Maybe I am not the only one interested by this. Again myself
and my company would consider to contribute.
Bruno
Scott O'Bryan wrote:
Bruno,
Actually, Trinidad does not yet work with portlets. :)
That being said
I added seven issues to the Trinidad Portlet component in Jira and one
to the MyFaces Portlet_Support component. That should get us started.
We'll have to have MYFACES-1448, MYFACES-1383, and ADFFACES-234 done
before we can start, however.
I do have a fix for MYFACES-1383, but it needs some
Or submit it soon rather.
Scott O'Bryan wrote:
I added seven issues to the Trinidad Portlet component in Jira and one
to the MyFaces Portlet_Support component. That should get us
started. We'll have to have MYFACES-1448, MYFACES-1383, and
ADFFACES-234 done before we can start, however.
I
all methods of HttpServlet
so I think its better that we don't test portlet patch implementation on
pluto.
On 10/10/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Scott,
testing against Pluto (Portlet RI)?
-M
On 10/10/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
I added seven issues
what ever we need to
support trinidad.
trindidad and tomahawk are both under myfaces, and many people including
myself are using both set of components.
On 10/10/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
To answer Mitthias, I'm going to be testing against Pluto and Oracle's
WSRP. I *MAY* add
Is there a place where we could store public API's that are not part of
Faces in MyFaces? Would this be the shared-impl package? We'll likely
need to support an interface to handle some of our filter
functionality from a portlet. This interface would need be referenced
by the MyFaces Bridge
Arash,
I'll get some JIRA tasks loaded up for this and you can have at it.
We're going to need to make some enhancements to the bridge as well and
we might need to have a Trinidad bridge which derives off the Generic
Bridge in MyFaces to handle some of the special cases that we can't
handle
enhancements to work with the portal system. Hopefully
we'll get Trinidad up to speed very soon.
-1 to reverting the renderkit to work with 1.4. It seems to me it's
taking a step backward, especially as we (or Adam rather) ramp up to
supporting JSF 1.2.
Scott O'Bryan
Bruno Bernard wrote:
I am
61 matches
Mail list logo
