I'll take care. On Fri, Nov 2, 2012 at 5:59 PM, Sebastien <seb...@gmail.com> wrote: > Hi Alec, > > If Sven or Martin agree with this solution for 1.5.9 & 6.3.0, I can attach > the patch(es) to the opened ticket if needed. (but to replace a word by > another, I am not sure my support will help that much! :) ) > > I also think that we can keep this AttributeAppender even with the changes > to be done for wicket7 (with the Martin's suggestion for instance). At > least I do not see yet any potential issue / unexpected behavior that can > happens, and we keep the advantage it provides... > > Best regards, > Sebastien. > > On Fri, Nov 2, 2012 at 4:21 PM, Alec Swan <alecs...@gmail.com> wrote: > >> Sebastien, thanks for reviewing and approving the proposal. So, what >> do we need to do to make it in 1.5.9? Or did you already check it in >> there? >> >> Thanks, >> >> Alec >> >> On Thu, Nov 1, 2012 at 6:04 PM, Sebastien <seb...@gmail.com> wrote: >> > Hi Alec, >> > >> > Thanks for having taking time to write the code snippet bellow, I better >> > understand your idea!.. >> > I did not realized you didn't want to use getCssClass, but I think it is >> > good solution anyway! It is easy for the user to replace >> > message.isInfo() ? ".my-ui-info" : ".my-ui-error" >> > by its custom method: getMessageCssClass(message.getLevel()) or something >> > equivalent as we spoke before, so that's fine for me. Well done! >> > >> > Thanks again & best regards, >> > Sebastien. >> > >> > >> > On Thu, Nov 1, 2012 at 11:57 PM, Alec Swan <alecs...@gmail.com> wrote: >> > >> >> @Sebastien The scenario you described it exactly the scenario I used >> >> to start this thread. Please read my original post. >> >> >> >> So, the solution is to change Wicket code >> >> FeedbackPanel.MessageListView#populateItem to use AttributeAppender >> >> instead of AttributeModifier as I suggested in my previous message. In >> >> addition, your code should override newMessageDisplayComponent(..) as >> >> follows: >> >> >> >> protected Component newMessageDisplayComponent(String id, >> >> FeedbackMessage message) { >> >> Component label = super.newMessageDisplayComponent(id, message); >> >> label.add(new AttributeAppender("class", new >> >> Model<String>(message.isInfo() ? ".my-ui-info" : ".my-ui-error"), " >> >> ")); >> >> return label; >> >> } >> >> >> >> This will set the style you want on <span> and will leave <li> >> unmodified. >> >> >> >> Why doesn't it work for you? >> >> >> >> Thanks, >> >> >> >> Alec >> >> >> >> On Thu, Nov 1, 2012 at 9:55 AM, Sebastien <seb...@gmail.com> wrote: >> >> > Hi, >> >> > >> >> > @Alec, the use case is the following: >> >> > Consider you are not the "owner" of the css-class(es). The css >> provider >> >> (a >> >> > ui-framework, a designer, ...) will provide one style by message level >> >> > (let's say .my-ui-warn, .my-ui-error, .my-ui-info, etc). So you will >> >> > override #getCssClass in order to return the corresponding css-class >> >> > depending of the level type (supplied as method's argument). But... >> the >> >> > provided class/style is designed to be applied *only* to one element. >> So, >> >> > if the css-class is applied onto both LI and SPAN, there will be a >> style >> >> > overlap which will result to a bad display... As the >> >> > message-level-css-class is *always* appended to both elements, there >> is >> >> yet >> >> > no other choice (I think) to have our own FeedbackPanel or extending >> the >> >> > existing one with the "hack" I provided earlier... >> >> > >> >> > @Sven: Thanks for your suggestion! It would result to a different >> >> component >> >> > but it is certainly more relevant... >> >> > >> >> > Best regards, >> >> > Sebastien. >> >> > >> >> > >> >> > On Thu, Nov 1, 2012 at 4:17 PM, Sven Meier <s...@meiers.net> wrote: >> >> > >> >> >> If you want to group messages you can easily use multiple feedback >> >> panels, >> >> >> each filtering by severity. >> >> >> >> >> >> Sven >> >> >> >> >> >> Sebastien <seb...@gmail.com> schrieb: >> >> >> >> >> >> >Hi, >> >> >> > >> >> >> >@Alec, unfortunately I think your workaround does not handle the >> case >> >> we >> >> >> do >> >> >> >*not* want the message-level-css-class on the SPAN, and that we >> still >> >> want >> >> >> >it on the LI... >> >> >> > >> >> >> >@Sven, well if the refactoring is planned for Wicket 7 (a question >> will >> >> >> >remain about doing something, backward compatible, for current >> >> versions), >> >> >> >then it changes things... >> >> >> >Then, I would maybe have a request about this refactored >> >> FeedbackPanel: I >> >> >> >would like to be able to have/display messages grouped by levels (so >> >> each >> >> >> >level is enclosed in its own container). That would simply mean that >> >> the >> >> >> UL >> >> >> >will becomes a repeater. For instance, if this 'grouping option' is >> not >> >> >> >activated, the repeater will iterate only once, with all feedback >> >> message >> >> >> >of any level type. If it is activated, the repeater will iterate as >> >> many >> >> >> >times as there is distinct message level types. And, last but not >> >> least, >> >> >> we >> >> >> >should be able to apply the message-level-css-class to this repeater >> >> (and >> >> >> >be able to *not* apply it to LI nor SPAN... so the loop is looped*). >> >> >> > >> >> >> >If you, dev-team, think this request is not relevant for >> wicket-core, >> >> >> >please keep in mind this need while refactoring so you may provide >> the >> >> >> >necessary/accessible things for the user wishing to *override* >> >> >> >FeedbackPanel to achieve this goal... >> >> >> > >> >> >> >Thanks in advance & best regards, >> >> >> >Sebastien >> >> >> > >> >> >> >(*) hazardous translation from French... >> >> >> > >> >> >> > >> >> >> >On Wed, Oct 31, 2012 at 11:37 PM, Alec Swan <alecs...@gmail.com> >> >> wrote: >> >> >> > >> >> >> >> So, the patch can be applied to 1.5.8 and will replace >> >> >> >> label.add(levelModifier); >> >> >> >> with >> >> >> >> label.add(new AttributeAppender("class", replacementModel)) >> >> >> >> >> >> >> >> You may want to add AttributeAppender to <li> as well. >> >> >> >> >> >> >> >> Alec >> >> >> >> >> >> >> >> On Wed, Oct 31, 2012 at 4:33 PM, Alec Swan <alecs...@gmail.com> >> >> wrote: >> >> >> >> > I suggest that instead of overriding CSS class on the <span> you >> >> >> >> > APPEND it to existing CSS classes. This will allow the user to >> >> specify >> >> >> >> > their own <span> CSS class in newMessageDisplayComponent(..) AND >> >> will >> >> >> >> > support backward compatibility. >> >> >> >> > >> >> >> >> > Sounds like a win-win to me. Thoughts? >> >> >> >> > >> >> >> >> > Thanks, >> >> >> >> > >> >> >> >> > Alec >> >> >> >> > >> >> >> >> > On Wed, Oct 31, 2012 at 1:17 AM, Sven Meier <s...@meiers.net> >> >> wrote: >> >> >> >> >> Hi, >> >> >> >> >> >> >> >> >> >> the CSS class could be changed in Wicket 7 only. Until you've >> >> >> migrated >> >> >> >> you >> >> >> >> >> can easily just use your own feedback component. >> >> >> >> >> >> >> >> >> >> Best regards >> >> >> >> >> Sven >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 10/30/2012 11:24 PM, Sebastien wrote: >> >> >> >> >>> >> >> >> >> >>> Hi, >> >> >> >> >>> >> >> >> >> >>> I also agree with Martin's points. Having no css-class on the >> >> span >> >> >> is >> >> >> >> the >> >> >> >> >>> best solution from my point of view too. >> >> >> >> >>> A little concern however. I think this kind of change is not >> >> exactly >> >> >> >> >>> "backward compatible". Sure, it is, for the java side, but I >> >> figure >> >> >> >> that >> >> >> >> >>> *many* users have wrote their own CSS for feedback panels and >> >> this >> >> >> will >> >> >> >> >>> probably results to bad display with this change. So, I am >> >> >> wondering if >> >> >> >> >>> this change will be considered as an "API break"? If yes, will >> >> you >> >> >> >> apply >> >> >> >> >>> it >> >> >> >> >>> also to 1.5.x (the original demand)? And, if the new version >> >> >> numbering >> >> >> >> >>> system in place applies to 1.5.x, does that means that it >> should >> >> be >> >> >> >> 1.6.0? >> >> >> >> >>> You see what I mean... it could lead to some >> misunderstanding!.. >> >> >> >> >>> >> >> >> >> >>> Also I like Sven's suggestion, but I am afraid that it will >> >> overlap >> >> >> >> with >> >> >> >> >>> #newMessageDisplayComponent(). As ListItem IS-A >> >> WebMarkupContainer, >> >> >> we >> >> >> >> >>> could do any customization from here. But, in this case (there >> >> is a >> >> >> new >> >> >> >> >>> #newMessageItem() method), the span element is not needed >> anymore >> >> >> and >> >> >> >> >>> therefore #newMessageDisplayComponent() neither. So, about the >> >> API >> >> >> >> break, >> >> >> >> >>> we are in situation :) >> >> >> >> >>> >> >> >> >> >>> Thanks & best regards, >> >> >> >> >>> Sebastien. >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> On Mon, Oct 29, 2012 at 6:18 PM, Joachim Schrod < >> jsch...@acm.org >> >> > >> >> >> >> wrote: >> >> >> >> >>> >> >> >> >> >>>> Hi, >> >> >> >> >>>> >> >> >> >> >>>> This would change be very well received, from my side. :-) >> :-) >> >> >> >> >>>> >> >> >> >> >>>> Cheers, >> >> >> >> >>>> Joachim >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> >> >>>> Martin Grigorov wrote: >> >> >> >> >>>>> >> >> >> >> >>>>> Hi, >> >> >> >> >>>>> >> >> >> >> >>>>> [X] Other suggestion: (please specify) >> >> >> >> >>>>> >> >> >> >> >>>>> Here is what I think it should be: >> >> >> >> >>>>> - <div> element should have class "feedbackPanel" (this is >> >> already >> >> >> >> the >> >> >> >> >>>> >> >> >> >> >>>> case) >> >> >> >> >>>>> >> >> >> >> >>>>> - <li> element(s) should have class that specifies the >> feedback >> >> >> >> >>>>> message level (currently by default Wicket sets >> >> >> "feedbackPanelLEVEL", >> >> >> >> >>>>> but this is configurable with >> >> >> >> >>>>> >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> >> >> >> >> >> >> >> org.apache.wicket.markup.html.panel.FeedbackPanel#getCSSClass(FeedbackMessage)) >> >> >> >> >>>>> >> >> >> >> >>>>> - the <span> should not have class at all (currently it has >> the >> >> >> same >> >> >> >> >>>>> class as the <li> element) >> >> >> >> >>>>> - the styling should be done with CSS selectors (e.g. >> >> >> >> >>>>> div.feedbackPanel; div.feedbackPanel li.alert-warn; >> >> >> div.feedbackPanel >> >> >> >> >>>>> li.alert-warn span; ...) >> >> >> >> >>>>> - if custom markup is needed then a custom FeedbackPanel is >> >> needed >> >> >> >> >>>>> (one that extends from the default FeedbackPanel or a >> >> completely >> >> >> new >> >> >> >> >>>>> one, it depends on the use case) >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> On Sun, Oct 28, 2012 at 6:03 PM, Sebastien < >> seb...@gmail.com> >> >> >> wrote: >> >> >> >> >>>>>> >> >> >> >> >>>>>> Hi, >> >> >> >> >>>>>> >> >> >> >> >>>>>> To sum-up this thread: we have a (not huge, but still) >> design >> >> >> issue >> >> >> >> >>>>>> that >> >> >> >> >>>>>> annoys several users. A patch* has been provided but some >> >> >> questions >> >> >> >> >>>>>> remains... >> >> >> >> >>>>>> Given this, I would suggest a kind-of vote about the >> several >> >> >> points >> >> >> >> >>>>>> discussed earlier, in order to enlighten the dev-team about >> >> the >> >> >> >> >>>> >> >> >> >> >>>> preferred >> >> >> >> >>>>>> >> >> >> >> >>>>>> choice of their (beloved) users.** >> >> >> >> >>>>>> >> >> >> >> >>>>>> Here are some possible options: >> >> >> >> >>>>>> [ ] Please apply the patch as-is. It currently provides 2 >> >> methods >> >> >> >> >>>>>> (#getListCSSClass and #getLabelCSSClass), #getCSSClass is >> >> marked >> >> >> a >> >> >> >> >>>>>> deprecated until marked as private (or removed) >> >> >> >> >>>>>> [ ] Do not apply the patch as-is, #getCSSClass should be >> kept >> >> >> (not >> >> >> >> >>>> >> >> >> >> >>>> marked >> >> >> >> >>>>>> >> >> >> >> >>>>>> as deprecated) >> >> >> >> >>>>>> [ ] Do not apply the patch as-is, I do not agree with the 2 >> >> >> method >> >> >> >> >>>> >> >> >> >> >>>> names. I >> >> >> >> >>>>>> >> >> >> >> >>>>>> would have preferred: (please specify) >> >> >> >> >>>>>> [ ] This is not an issue; this does not need to be >> "corrected" >> >> >> >> >>>>>> [ ] Other suggestion: (please specify) >> >> >> >> >>>>>> >> >> >> >> >>>>>> Thanks in advance for your contribution, >> >> >> >> >>>>>> Sebastien >> >> >> >> >>>>>> >> >> >> >> >>>>>> (*) https://issues.apache.org/jira/browse/WICKET-4831 >> >> >> >> >>>>>> (**) Sure, dev-team opinion is also kindly asked! :) >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> >> >>>> Joachim >> >> >> >> >>>> >> >> >> >> >>>> -- >> >> >> >> >>>> >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> >> >> >> >>>> Joachim Schrod, Roedermark, Germany >> >> >> >> >>>> Email: jsch...@acm.org >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> --------------------------------------------------------------------- >> >> >> >> >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >> >> >> >>>> For additional commands, e-mail: >> users-h...@wicket.apache.org >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >> >> >> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >> >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >> >> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >>
-- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org