Adam,
I agree with many of your points about the reflection. My comment was
mainly on casting and casting was still a realitivly slow operation as
of JDK 1.4 (I havn't tested 1.5). Still, you have a valid point that
it's done only once per class-loader per context. My question remains,
Scott,
A few points.
First, I said only that initializing with construction is more
robust then separating the two, and only that. That's plainly true.
Why you want to turn that around to ad hominem generalizations
is beyond me and not productive.
Second, it certainly is a good point that you
Adding getInstance() to the configurator will either force us to cast in
a bunch of different places or to expose the GlobalConfiguratorImpl's
api to the rest of the world (which I don't want to do because they are
applicable ONLY to global configurator. And it won't lock us into an
API we
Scott,
OK, well, I just went ahead and implemented what I was trying
to say, to see if I'd run into the problems you're describing. I didn't...
(It's 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
Adam,
Well, you basically implemented one of the solutions I said I didn't
like earlier, but oh well. And there are a number of places you need to
cast. So the concerns are still valid.
The one question I do have is why does getInstance take in an
ExternalContext? I'm assuming it's
BTW- There are some API inconsistencies that need to be documented. The
beginRequest and endRequest methods on the Global configurator object
are designed to be run at the beginning and end of each request phase
(In servlet there is one and in Portlet there are two) where as the
Configurator
On 12/21/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
Adam,
Well, you basically implemented one of the solutions I said I didn't
like earlier, but oh well. And there are a number of places you need to
cast. So the concerns are still valid.
Well, I don't get that claim, as I didn't add a
Scott,
Why wouldn't methods that hook the start and end of
the physical request be generically useful? Note that
in my scheme, these'd just be empty methods, not
abstract methods (or interface methods) that every
configurator has to implement.
For that matter, wouldn't we want to make the
That method could easily be a static method on Configurator
in my scheme.
-- Adam
On 12/15/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
I just got one more example from your other input.
I'm probably going to be adding a disableConfiguratorForRequest method
(or something similar) to the global
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
Well, in this specific instance, it therefore doesn't bloat every
configurator, since it only appears in one location.
-- Adam
On 12/19/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
I'm still wondering why we should bloat the API of every configurator.
And not ALL of the methods I'm looking at
On 12/19/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
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
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
Scott,
You're explaining very well why you want to put this in IMPL.
And why you need a different instance that handles this on
behalf of all other configurators. You're not yet explaining
why you need a whole class to accomplish this, as opposed
to a standard decorator or CoR pattern, etc. I
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
We're in the process of finding a home. It's looking like the RI is
going to live at JBoss, at least for now. They are trying to fastrack
the project and there was some concern that the Apache community might
be too process-heavy to allow the project to be developed in a timely
manner. As
On 12/15/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
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
thanks,
m
On 12/15/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
We're in the process of finding a home. It's looking like the RI is
going to live at JBoss, at least for now. They are trying to fastrack
the project and there was some concern that the Apache community might
be too process-heavy
Further investigation:
PortletExternalContext can be removed. There is a possibility that it
will need to be added again for JSR-301 but that depends on interfaces
which aren't defined yet so I'm cool on getting rid of it till we need it.
The ServletExternalContext is used in the
On 12/15/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
Adam Winer wrote:
Therefore if these or other things arise, having an API for a global
cofigurator will be more flexible in the future because we'll be able to
add to this API would breaking binary compatibility. If we start
returning
I just got one more example from your other input.
I'm probably going to be adding a disableConfiguratorForRequest method
(or something similar) to the global configurator to support disabling
the configurator services from running. It's cleaner then an attribute
me-thinks and will help if
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
Hey everyone,
As some of you know I have been working on a bunch of enhancements in
order to get Trinidad prepared to work on a portal environment. While
there is still some myfaces bridge work which needs to be done in order
to call this a complete success, I would like to get the work I
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 think we should:
-
25 matches
Mail list logo
