n Wed, Nov 7, 2012 at 1:45 AM, Alec Swan wrote:
> >>
> >> Martin, could you please merge your changes to 1.5.9 branch?
> >>
> >> Thanks,
> >>
> >> Alec
> >>
> >>
> >> ------ Forwarded message ----------
> >>
Is anybody merging this in 1.5.9?
On Fri, Nov 2, 2012 at 11:37 PM, miteshaegis wrote:
> Hi,
>
> You can use set of class and set css on div class easily.
>
> Thanks!
>
>
>
> -
> JBoss Developers || JBPM Workflow
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.
Hi,
You can use set of class and set css on div class easily.
Thanks!
-
JBoss Developers || JBPM Workflow
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Custom-CSS-for-Feedback-message-is-broken-in-1-5-tp4653166p4653593.html
Sent from the Users forum mailin
I've removed the class attribute from markup.
The changes are on master and wicket-1.5.x branch.
Sven
On 11/02/2012 08:48 PM, Alec Swan wrote:
I don't see 1.5.9 branch either and I don't see the changes in 1.5.x
branch. Martin, where did you check your changes in?
Thanks,
Alec
On Fri, Nov 2
I don't see 1.5.9 branch either and I don't see the changes in 1.5.x
branch. Martin, where did you check your changes in?
Thanks,
Alec
On Fri, Nov 2, 2012 at 12:56 PM, Sebastien wrote:
> Hi Martin,
>
> Tested & approved! Works like a charm...
>
> I tested upon master branch (6.3.0-SNAPSHOT), be
Hi Martin,
Tested & approved! Works like a charm...
I tested upon master branch (6.3.0-SNAPSHOT), because I do not see were
wicket-1.5.9 branch is... But I guess it behaves exactly the same.
Just a little note; on the version I pulled I still have class="errorlevel"
in the associated markup (Sven
Done!
Please confirm that this is enough for now.
On Fri, Nov 2, 2012 at 7:01 PM, Sebastien wrote:
> Great! Thanks Martin!
>
> On Fri, Nov 2, 2012 at 5:01 PM, Martin Grigorov wrote:
>
>> I'll take care.
>>
>> On Fri, Nov 2, 2012 at 5:59 PM, Sebastien wrote:
>> > Hi Alec,
>> >
>> > If Sven or Ma
Great! Thanks Martin!
On Fri, Nov 2, 2012 at 5:01 PM, Martin Grigorov wrote:
> I'll take care.
>
> On Fri, Nov 2, 2012 at 5:59 PM, Sebastien 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.
I'll take care.
On Fri, Nov 2, 2012 at 5:59 PM, Sebastien 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
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
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 wrote:
> Hi Alec,
>
> Thanks for having taking time to write the code snippet bellow, I better
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 custo
@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
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
If you want to group messages you can easily use multiple feedback panels, each
filtering by severity.
Sven
Sebastien 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
@Sebastien, my original post in this thread would have been satisfied
with my solution which appends the CSS class instead of replacing it.
And this solution is backward compatible.
If there is a different scenario which required *not* having a
message-level-css-class, maybe we should start a sepa
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
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 as well.
Alec
On Wed, Oct 31, 2012 at 4:33 PM, Alec Swan wrote:
> I suggest that instead of overriding CSS
I suggest that instead of overriding CSS class on the you
APPEND it to existing CSS classes. This will allow the user to specify
their own CSS class in newMessageDisplayComponent(..) AND will
support backward compatibility.
Sounds like a win-win to me. Thoughts?
Thanks,
Alec
On Wed, Oct 31, 2
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 poin
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
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:
> - element should have class "feedbackPanel" (this is already the case)
> - element(s) s
[X] Other suggestion: don't have a class on the span, or even better,
don't have the span element at all inside the list-item
For any customisations beyound this, just create your own FeedbackPanel,
it's easy and gives complete control.
On Sun, Oct 28, 2012, at 17:03, Sebastien wrote:
> Hi,
>
>
[X] Other suggestion:
I agree with Martin's points, especially the 3rd one (span should have no CSS
class).
To ease extending of FeedbackPanel I'd suggest to delegate #newItem() of the
nested MessageListView to a new protected method #newMessageItem() in
FeedbackPanel. (Similar to DataTable#n
Hi,
[X] Other suggestion: (please specify)
Here is what I think it should be:
- element should have class "feedbackPanel" (this is already the case)
- element(s) should have class that specifies the feedback
message level (currently by default Wicket sets "feedbackPanelLEVEL",
but this is confi
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
Martin Grigorov wrote:
> Hi,
>
> Here is an example of the produced markup for an single INFO message:
>
>
>
>
>
> Saved model [TestInputObject
> stringProperty = 'test', integerProperty = 100, doubleProperty = 20.5,
> booleanProperty = false, integerInRangeProperty
Hi,
>that a CSS class applies both to LI and to below-SPAN element
I agree, applying the CSS class on the LI would be sufficient.
But the current duplication should do no harm in most situations. Except
where you cannot change the CSS, of course.
Sven
On 10/25/2012 01:07 AM, Joachim Schrod w
Hi,
Here is an example of the produced markup for an single INFO message:
Saved model [TestInputObject
stringProperty = 'test', integerProperty = 100, doubleProperty = 20.5,
booleanProperty = false, integerInRangeProperty = 50, urlProperty =
http://wicket.apache.or
Paul Bors wrote:
> 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
I just want to add m
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 migrat
{
> 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-
> F
et.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, Seb
,
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
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 wrote:
> Alec, you are right, I did thought about that.
>
> My reflec
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 n
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 wrote:
> Done, https://issues.apache.org/jira/browse/WICKET-4831
> Please let me know if your encounter any issue (wrong base cod
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 wrote:
> Please open a Jira issue and provide a patch as you sugge
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 priva
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
Because if you use Twitter bootstrap and add "alert alert-info" CSS
classes, then it's not going to look nice if it's applied to and
.
On Sat, Oct 20, 2012 at 3:05 PM, Sven Meier wrote:
> I was just going to ask you why you don't overwrite #getCSSClass().
>
> What harm does it if the CSS class i
Hi,
I also suffer from this feature (having the same CSS class applied onto
both li and span) since a long time.
@Sven, this could be important to remove one or the other class attribute
in case the class return by getCSSClass() is not from your own CSS (you
want to apply jquery-ui style for insta
I was just going to ask you why you don't overwrite #getCSSClass().
What harm does it if the CSS class is on the too?
Sven
On 10/20/2012 11:01 PM, Alec Swan wrote:
Note that I need to set CSS styles on the label () and not the
list item () and hence cannot override getCSSClass() because it is
Note that I need to set CSS styles on the label () and not the
list item () and hence cannot override getCSSClass() because it is
applied to both.
On Sat, Oct 20, 2012 at 2:58 PM, Alec Swan wrote:
> Hello,
>
> This Wiki page explains how to add custom CSS styles to Feedback
> messages in 1.4+:
>
44 matches
Mail list logo
