Jean, thanks for the reply.
I did create a Jira issue and went ahead and tried to see if I can understand
Trinidad well enough to supply a patch, then asked for opinions.
Looking back I now think the way I implemented it can be both improved and
simplified.
If you (or somebody else) shares her opinion on the principal way to implement
it, I'll give it a second try.
The main problem is that there also is the message icon, so not only should the
required icon position be configurable, but when doing that the message icon
should be generalized as well.
Then to do it properly the relative positioning of the two icons should be
somehow configurable, too.
Then again it maybe makes sense to be able to configure both a start and a
leading required or message icon, so that for example a labels for a field with
a message could look like this:
--> First name <--
Any suggestion how the skinning selectors should look like?
Jeanne Waldman wrote:
Stephan,
This would have been a good skinning feature to add, so that anyone else
that
wants to do this could use skinning to change the position of the field
label.
With a skinning property, a person that wants his "*" behind field
labels would
simply have to add to their skin something like:
.AFLabelPosition:alias { -tr-before-label: false }
And then the renderers of labels would check this skin property when
they are rendering the label,
and render it either in front or behind.
- Jeanne
Stephen Friedrich wrote, On 4/13/2008 11:26 PM PT:
Blake, in general you point of view is a very theoretical one from a high
ebony tower. Do you say so in english? ;-)
In real life those private methods do make using Trinidad more cumbersome
that it needs to be.
For example it is currently not possible to make a simple change like
moving
"*" _behind_ field labels.
I agree that there should be a well defined contract how to adjust
behaviour
- in theory. Practically speaking to fix that little issue, I had to
understand trinidad sources, create a patch and recompile that whole damn
thing.
Not really a better solution, isn't it?
If you don't personally agree to go through each and every source file in
Trinidad and fix those issues with hardcoded, unchangeable behaviour,
then
please have some understanding for the purpose of the request.
It goes without saying that overriding protected methods in trinidad
interal
sources can break if you blindly update to the next trinidad version.
Yet, I better like to have that documented in my app, than having to
document
"well, and then you have to download trinidad sources, make these and
that
patches, check if they are still compatible with the new trinidad
version,
recompile the lib and ship with that modified copy of trinidad".
Blake Sullivan wrote:
Andrew Robinson said the following On 4/10/2008 1:36 PM PT:
I wasn't suggesting blind removal. IMO final should rarely ever be
used, for open source it almost never does anyone any good.
Really. Why would good programming practice in the closed source
world be bad programming practice in open source? If anything, it is
easier to change these restrictions in open source, if necessary.
What you are really saying is that you disagree with the decisions
made by the class designers with respect to the trade-offs between
intertwining the subclasses and superclasses and the convenience of
tweaking implementation.
There is a real cost to the maintainability and evolution of the
superclasses if they are burdened with huge numbers of protected
hooks. Especially if those hooks became protected without the
necessary work to nail down their precise contract.
I would
suggest a renderer-by-renderer approach though, not method-by-method
as that would take too long to file that many bugs.
Right now Trinidad and facelets are by far the most inflexible open
source code I have worked with.
Functions are private or final because the class designer because
those aren't designed extension points. I suspect that Trinidad and
Facelets are being honest about this. I would be suspicious of a
class with huge numbers of protected methods--it is doubtful that all
of the possible interactions have actually been considered.
One of the advantages of open source is that it is easy to test
opening up particular pieces and ask for your change to be approved.
Both over-use final and both assume
that out-of-the box behavior is enough fore everyone's needs. For
Trinidad renderers, many only expose encodeAll as protected then do
most of the work in private methods. As a result a person needing to
customize a renderer has to use copy & paste (generate an entirely new
renderer using the source of the core one) which really sucks for
maintenance.
On the other hand, the renderer author gains isolation and the
superclasses don't need to add every single hook that any possible
subclasser might want.
If there really are huge chunks of interesting code that should be
shared in this case, they can be broken out into utilities and shared
that way.
-- Blake Sullivan
-Andrew
On Thu, Apr 10, 2008 at 1:48 PM, Andy Schwartz
<[EMAIL PROTECTED]> wrote:
On Thu, Apr 10, 2008 at 1:36 PM, Andrew Robinson
<[EMAIL PROTECTED]> wrote:
> +1 for:
> - removing most final modifiers
> - going from private to protected on most renderer methods
Not sure how much my opinion counts, since I am a new face around
here, but I am -1 on blindly removing most final modifiers, or
promoting most private methods to protected. Methods may have been
intentionally marked as final by the Renderer author, eg. to enforce
the fact that the method is itself a convenience for some other
method
which provides the actual implementation. And many if not most of
the
private methods are not necessarily good additions to the protected
API, since they were not designed with extensibility in mind.
I understand the desire for more flexibility, so if the community
feels this is important, then let's solve the problem. However, I
don't think that the way to achieve this goal is by sacrificing basic
design principles. If we want better protected APIs, then let's work
on adding them - arbitrarily removing most final/private modifiers
isn't the way to get there.
BTW, (referring back to early comments on this thread) I don't see
how
this is an open vs. closed source issue. The same API design
principles apply to both cases.
> - and adding more customization hooks in the renderers
Now this sounds like a better idea. In some cases this may mean
making existing final/private methods non-final/protected, but we
should put some thought into which cases require this rather than
doing this in an arbitrary manner.
Andy
