Yes, but how would that affect other projects that do expect the CSS to be
applied to the LI or SPAN?
Come to think about it, I could very simple replace the content of both with
my own panels right?
I think this is a project specific requirement and as such should be handled
by extending from Wicket's code and adjusting the behavior as per the
specific project requirements thus I don't see a real need for WICKET-4831
"Split custom CSS for Feedback message (list and label)".
If that's the case, then I should start flooding the wicket Jira queue with
all the specific needs for my own projects.
I only gave an example of how one can have full control with little code :)
~ Thank you,
Paul Bors
-----Original Message-----
From: Sven Meier [mailto:s...@meiers.net]
Sent: Wednesday, October 24, 2012 3:04 AM
To: users@wicket.apache.org
Subject: Re: Custom CSS for Feedback message is broken in 1.5
The point is that he does *not* want getCSSClass() to be applied to the
<li>.
Sven
On 10/24/2012 12:24 AM, Paul Bors wrote:
> There is nothing stopping you from extending from the FeedBackPanel
> and override the HTML the Wicket component is using.
>
> This is how we did it.
>
> The HTML:
> <html xmlns:wicket="http://wicket.apache.org";>
> <wicket:panel>
> <div wicket:id="feedbackul" class="feedbackMessages">
> <div wicket:id="messages">
> <span wicket:id="message">[Feedback message(s)]</span>
> </div>
> </div>
> </wicket:panel>
> </html>
>
> And the Java:
> import org.apache.wicket.feedback.IFeedbackMessageFilter;
> import org.apache.wicket.markup.html.panel.FeedbackPanel;
>
> public class MyFeedbackPanel extends FeedbackPanel {
> private static final long serialVersionUID = 1L;
>
> public MyFeedbackPanel (String id) {
> this(id, null);
> }
>
> public MyFeedbackPanel (String id, IFeedbackMessageFilter filter) {
> super(id, filter);
> setOutputMarkupId(true);
> }
> }
>
> Our application wide CSS:
>
> /* FEEDBACK MESSAGES */
>
> .feedbackMessages {
> padding-left: 0;
> padding-top: 0;
> text-align: left;
> margin-left: 0;
> margin-top: 0;
> padding-bottom: 1em;
> }
>
> .feedbackMessages div {
> padding: 0.5em;
> font-size: xx-small;
> border: none;
> }
>
> .feedbackMessages div.feedbackPanelERROR {
> background-color: lightsalmon;
> border: 1px solid darkred;
> }
>
> .feedbackMessages div.feedbackPanelWARNING {
> background-color: #FFB90F;
> border: 1px solid darkgoldenrod;
> }
>
> .feedbackMessages div.feedbackPanelINFO {
> background-color: lightgreen;
> border: 1px solid darkgreen;
> }
>
> This code was written for Wicket 1.3.x and migrated to 1.5.x w/o any
> changes (we're not yet up to 6.x).
>
> ~ Thank you,
> Paul Bors
>
> -----Original Message-----
> From: Alec Swan [mailto:alecs...@gmail.com]
> Sent: Tuesday, October 23, 2012 6:08 PM
> To: users@wicket.apache.org
> Subject: Re: Custom CSS for Feedback message is broken in 1.5
>
> Sebastien, List, ListItem and Label make sense to me and match the
> terms used in FeedbackPanel class. However, I try not to get too hung
> up on naming for the sake of making progress :)
>
> On Tue, Oct 23, 2012 at 3:39 PM, Sebastien <seb...@gmail.com> wrote:
>> Alec, you are right, I did thought about that.
>>
>> My reflection was that getListCSS applies to list *element* (li) and
>> it is quite easy to understand that getLabelCSS (which applies to the
>> label) stands for the message itself (which is a span element).
>>
>> But in another hand we can imagine that these naming are related to
>> wicket
>> *component* instead; so, it is true that it would technically best to
>> have getListItemCSS (applies to ListItem) and getLabelCSS (applies to
> Label).
>> But what if the user overrides #newMessageDisplayComponent and return
>> something other than a Label? A Panel for instance? Maybe getLabelCSS
>> appears to not be logical anymore in this context: we have a
>> getListItemCSS which still applies to a ListItem and a getLabelCSS
>> which applies to... a Panel.
>>
>> In another hand (again), we can also imagine that the HTML markup is
>> getting "overridden" (while extending FeedbackPanel), li and span
>> elements may have been replaced by other elements (2 divs for
>> instance)... So getListCSS may also not be logical in this context,
>> and would have better been getContainerCSS or something like that...
>>
>> Not easy to find right naming; its a kind of Ouroboros* ** discussion
>> in this case...
>> But at the end, will the user better understand getListCSS or
>> getListItemCSS? Also, is getLabelCSS the best? What about getMessageCSS?
>>
>> That's all open questions... I wish you a good night with that! ;)
>> Sebastien
>>
>> * http://en.wikipedia.org/wiki/Ouroboros
>> ** I am pretty sure this term has previously been used in this
>> mailing list but I don't remember who... So there is a credit for
>> someone somewhere :)
>>
>>
>> On Tue, Oct 23, 2012 at 9:15 PM, Alec Swan <alecs...@gmail.com> wrote:
>>
>>> Technically it should be getListItemCSS, not getListCSS. Or maybe
>>> have all three getListCSS, getListItemCSS and getLabelCSS
>>>
>>> On Mon, Oct 22, 2012 at 12:46 PM, Sebastien <seb...@gmail.com> wrote:
>>>> Done, https://issues.apache.org/jira/browse/WICKET-4831
>>>> Please let me know if your encounter any issue (wrong base code for
>>>> instance) or if you have any questions...
>>>>
>>>> Thanks,
>>>> Sebastien.
>>>>
>>>> On Mon, Oct 22, 2012 at 8:06 PM, Sven Meier <s...@meiers.net> wrote:
>>>>
>>>>> Please open a Jira issue and provide a patch as you suggested.
>>>>>
>>>>> Thanks
>>>>> Sven
>>>>>
>>>>>
>>>>>
>>>>> On 10/21/2012 01:06 AM, Sebastien wrote:
>>>>>
>>>>>> Sven,
>>>>>>
>>>>>> If you agree to have two methods: getListCSSClass and
>>>>>> getLabelCSSClass (which apply respectively on li and span), and
>>>>>> mark getCSSClass as deprecated (until marked as private), then
>>>>>> the path is ready for branch wicket-1.5.x. I am waiting for your
>>>>>> go-ahead to send the patch
>>> somewhere
>>>>>> or
>>>>>> submit the pull request on github.
>>>>>>
>>>>>> If you do not agree, please tell me what I can do.
>>>>>>
>>>>>> Thanks & best regards,
>>>>>> Sebastien.
>>>>>>
>>>>>>
>>>>>
>>> ------------------------------**------------------------------**----
>>> -
>>> ----
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<
>>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
