Gerhard Petracek said the following On 3/11/2008 12:01 AM PT:
hello blake,
i completely agree.
as i said (see [1]):
it's an independent implementation i already have. so i'm able to
provide it.
i would appreciate if you (or someone else) provide an implementation,
which covers all requirements.
support for:
- subforms
- different types of focus handling
What types?
- conventions
What conventions?
We are looking for actual use cases as opposed to "support everything
that this piece of code supports".
-- Blake Sullivan
and of course:
the solutions shouldn't break backward compatibility.
regards,
gerhard
[1] http://www.nabble.com/-Trinidad--subform-defaultCommand-p15815227.html
2008/3/11, Blake Sullivan <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
Gabrielle Crawford said the following On 3/10/2008 5:50 PM PT:
>
> Gerhard Petracek wrote:
>> hello gabrielle,
>>
>> thank you for joining the discussion!
> :-)
>>
>> as i said:
>> it isn't a replacement of the current mechanism!
>> it's just an additional/alternative approach and you are free to
>> activate it within the web.xml - including all advantages and
>> disadvantages.
>> (in most cases every solution provides advantages and
disadvantages.)
> sure, but alternative or not I'm still -1. :-(
I would rather have one mechanism that does the whole job rather than
two that partially solve the problem and then have to explain when you
should use one rather than the other.
-- Blake Sullivan
>>
>> the whole issue is based on common requirements of real world
projects.
>> i'm sure that there is a reason for the current approach. however,
>> there are also other opinions out there.
>> so it would be great to alternatively support other common
requirements.
> Sure, I'm not saying there isn't a problem, I'm just saying I don't
> like this particular solution.
>>
>> the current default command mechanism is very restricted in view of
>> focus handling.
>> -> the patch provides an alternative focus handling.
> Can you give an example use case?
>>
>> concerning conventions:
>> what are your counter-arguments?
>
> Well, first of all it makes the id's longer which has a perf impact.
>
> But far more important is that I believe API's should be explicit,
> naming conventions are not explicit, for example it makes it
difficult
> for a DT to do something useful.
>
> Thanks,
>
> Gabrielle
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
