What's the JIRA number?
What exactly are your requirements? I wouldn't over-design it by putting
in too many hooks.
- Jeanne
Stephen Friedrich wrote, On 4/14/2008 2:22 PM PT:
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
