Font Colour of <mak:response/>.

[ghost]

Reported by Chucky on 17 May 2003 22:33 UTC The colour for success responses is forced to "green" a for errors is "red". It could make a problem if the bgcolour is "green" or "red"

(Note: I have no f%%king clue about how the h$ll fulfill a f%%king bug!) ;-)

Kisses Chucky

Migrated-From: http://trac.makumba.org/ticket/442

[ghost]

Comment by @cristianbogdan on 18 May 2003 20:59 UTC some sort of design decission needs be made here

one alternative:

or we may want to have parts of the pages that are executed only in case of succes... ........ please susggest

[ghost]

Comment by Chucky@BEST.eu.org on 20 May 2003 18:18 UTC I like more the first alternative.

We could have something like: <mak:response [successColor="color"][failureColor="color"]/>

The text in brackets is optional. I want to mean that it could be one of these: Simply:

Choose the color in case of success:

Choose the color in case of failure:

Choose both colors:

[ghost]

Comment by @stefanb on 20 May 2003 21:25 UTC apart from specifying color it might be good to get full control over it's appearance, by getting just the text with no html tags around colorize="false" (would be true by default for backwards compatibility)

Probably even better is to give it some standard makumba parameters: printVar="bla", where bla will be plain String with the message var="result", where result will be a boolean: true=ok, false denoting a failure

That way app developer gets full control of what he wants to do with the message (eg if ok just ignore it, if failure show it in javascript alert box).

[ghost]

Comment by @frederikhabils on 20 May 2003 22:24 UTC BTW, this may interact with bug 101 comment 2.

I like Stefan's ideas (colorize, var, printVar), very general :-)

The colorize tagParam seems similar to html="true" for text, but not entirely, so new parameter name appropriate. Say, I wonder now if the mak:response is past thru the text2html filter.

Still, I'm a bit in doubt, because printVar and var are generally supposed to reflect the same 'var'... So perhaps it could be

<mak:response success="..." var="..." printVar="..." exceptionVar="..." colorize="false|true" successColor="..." failureColor="..." />

-> success: boolean -> var: String - the basic message -> printVar: String - the colorized message -> exceptionVar: the Throwable (or null) -> actually: success = (excVar==null) -> etc

[ghost]

Comment by @stefanb on 21 May 2003 07:42 UTC

Still, I'm a bit in doubt, because printVar and var are generally supposed to reflect the same 'var'... So perhaps it could be khm we have some inconsistency here: for int enum fields the var is integer, while printVar is string but for pointers fields var is a pointer and the printVar is pointer.toExternalForm() while it could easily be target's title (but is not, because we can easily specify what field of the target we want to display)

So, i guess it makes sense to put there what will actually be needed by the programmer. Will they need both "Changes done" and "Changes done" at the same time or just one of them, in which case colorize can specify which one to put in printVar.

If we go for "success" parameter we might think of renaming to "successVar", because at first it seems that it is used to specify default message at success (success="everything went ok"), or evil programmer might even want to write success="false" ;-).

for the curious ones, here's the response tag source: http://cvs.makumba.org/classes/org/makumba/controller/jsp/ResponseTag.java http://cvs.makumba.org/classes/org/makumba/controller/http/Responder.java

[ghost]

Comment by @cristianbogdan on 21 May 2003 08:58 UTC guys, i really hate var and printVar for all the scriplet stuff, so i'd appreciate if we could use some other vocabulary especially when it's not consistent

about colors, it really seems to me that if today we want to format colors differently for success and failure, tomorow we'll want to format fonts, paragraphs, show dialog boxes and so forth. so limiting the design to colors is i think a missed oportunity

as Stefan noted, we have two parameters here:

• whether the form was succesful (boolean). there is makumba.succesfuResponse already set. we should either use that, or deprecate it
• the message (string). there is makumba.response already set. we should either use it or deprecate it...

my opinion is:

• keep the curernt mak:response but deprecate it, maybe add some color, font and other html stuff like suggested in bug 101

• it strikes me that we can have no special makumba tag, just use attributes and the results of bug 62:

<%-- test whether we respond to a form or not --%>

if we want to have special tags, i still think the best solution is along the lines of .... .... .... .... to reduce the number of tags, we can go further simplifying this design: .... .... that would entail just adding the "for" parameter to mak:response...

[ghost]

Comment by @cristianbogdan on 21 May 2003 09:26 UTC as per bug 442 comment 8, we have another proposal

" > or even " >

[ghost]

Comment by @cristianbogdan on 21 May 2003 09:37 UTC sorry, in comment 7 i mean bug 62 comment 8

[ghost]

Comment by milerosu@bestmail.us on 21 Apr 2005 09:05 UTC I have played a bit and implemented a version of mak:response with one parameter called format which can be html or simple. The default behaviour is the html(coloured) one.

But i can implement a better solution based on the comments above. Or i can commit the changes.

i must mention that i would need this simple formatting to get rid of attributes, but be able to write an alert in js.

[ghost]

Comment by @stefanb on 24 Apr 2005 10:31 UTC (In reply to comment #9)

I have played a bit and implemented a version of mak:response with one parameter called format which can be html or simple. The default behaviour is the html(coloured) one. I'd prefer "plain" over "simple", as simple can be stretched to various meanings.

It seems that we didn't think of getting the success variable at all here, eg a bolean value into a variable denoted by some tag's attribute

or we could extend the new format attribute with boolean setting:

with possible results: html:Changes done plain:Changes done boolean:true

if these are combined with additiona var attribute we could get all the needed info from the tag, but am not sure how well it plays with jstl.

[ghost]

Comment by @manuelbernhardt on 6 Jun 2009 13:54 UTC this was fixed by Jasper some time ago, and is documented at

http://new.makumba.org/configuration/configuration.html#Controller+behavior+[controllerConfig]

the property useDefaultResponseStyles makes it possible to deactivate the default green/red and to use two CSS classes (makumbaResponse and makumbaSuccess) instead