hello, let's talk about a different implementation later on.
-> i would like to finish the discussion for now. in my opinion there won't be an agreement on the available alternative. furthermore, i'm not the advocate of this alternative. i already expected that there are too different experiences and opinions. the current implementation is basically ok. however, i also share the opinion that the current implementation is insufficient for several common requirements. it was just a try to provide an optional implementation, which is alreadyavailable and offers some advantages and alternative/different concepts. *sorry* for the abrupt interruption and thank you for your participation. to be continued... :) regards, gerhard 2008/3/11, Gabrielle Crawford <[EMAIL PROTECTED]>: > > Hi, > > I don't think it's up to us to provide an api if we don't agree with the > one you provided. I think you need to > > 1] define your use cases with specific examples, saying "different types > of focus handling" is vague. > > 2] come up with a new approach that we can agree on. > > > Thanks, > > Gabrielle > > Gerhard Petracek wrote: > > > 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 > > - conventions > > > > 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 > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
