content to show only if an expression has [not] a certain value

[ghost]

Reported by @cristianbogdan on 24 Oct 2002 23:45 UTC usually when a mak:value is nil, the JSP author wants to show some text instead, and might not want to show some other text, which is shown only if the value is not-nil

this feature has been requested in various forms but i think the best idea came from some meeting involving webmasters and built upon by me and Stefan

confirmed: confirmation not known mak:before deals with the first mak:value or mak:list/object (!) that comes after it. mak:after does the same with the mak:value/list/object before it one can also imagine which would just print the field description from the MDD ; comment Migrated-From: http://trac.makumba.org/ticket/62

[ghost]

Comment by @cristianbogdan on 18 Apr 2003 19:42 UTC it seems that this is the issue that causes the most java scriplets in present code.

fixing this would dramatically diminish FLE incidents (see bug 5, bug 391)

in order to have as much power as possible, i suggest an if-like test

... expr is any oql expression including expr1<>nil or expr1=nil. if the expression is not null and not zero, the is executed. simple design. if this design is chosen, the expression will be evaluated in OQL (in the database=>fast). i know this eliminates the possibility of doing more sophisticated processing to the level of java, but being at that level would need scriplets anyway. besides, there is room for OQL improvement (bug 26, bug 27) N.B. this is very easy to implement

[ghost]

Comment by @cristianbogdan on 18 Apr 2003 21:51 UTC or should mak:test in comment 1 be called mak:if? cause there seems to be a need for a mak:else as well... but all these (mak:else, mak:switch, mak:case) can be done with mak:test, with no difficulties.

also, there seems to be a need to display only things if a mak:list is empty (or only if it has elements). this can be done with maxCountVar but that's a scriplet... the design should allow for showing things before and after the list. bug 65 proposes , similarly one can have and then one can think of . it looks a bit more intuitive to have these things done by separate tags () rather than forcing the design of to accomodate empty/full lists.

[ghost]

Comment by @frederikhabils on 20 May 2003 20:51 UTC my current opinion on this point

I believe I understand the idea of

name: ... valid until: or easier: so yeah, I believe I'm in favour of if/else tags (and elsif ?) In practice, while there are now to bring values to the java namespace for if-testing, we'll then have scriptlets to bring java- variables to Attribute namespace: <% pageContext.setAttribute("now", new Date()); %> About comment 0: - it took me some time to understand and visualize this thing. IMHO, too complicated, and compared to mak:if far less powerful. Not in favour. - I think the null-value replacement text, is the most common, and should be provided with highest priority. And perhaps a shorter statement than the mak:test/if would be even nicer, for the simplest cases: e.g. sorry, not on icq (the question being: should the default value be shown only for NIL or also for blank? probably for both)

[ghost]

Comment by @stefanb on 20 May 2003 21:13 UTC donno if it makes sense reinventing if else and other tags that are already implemented as a part of standard taglib: http://java.sun.com/products/jsp/jstl/ http://jakarta.apache.org/taglibs/doc/standard-doc/intro.html

with example for conditional formatting http://javaalmanac.com/egs/javax.servlet.jsp.jstl.core/if.html?l=new

Reinventing a standard taglib should only be done if there is no other (easy) way to use makumba data in test/if/choose/when/otherwise... expressions.

[ghost]

Comment by @cristianbogdan on 21 May 2003 00:29 UTC about comment 4: i fully agree with JSTL and i think it's the future for such stuff in makumba (see bug 9). there are 2 short-term considerents though

1) in the GA it was decided that avoiding workarounds is a main prio. now scriplets are not a workaround as such, but var= and printVar= lead to FLE workarounds and cryptical things (instanceof tests, null tests, casts) and other stuff. having this implemented early will avoid a large quantity of java scriplets, resulting in cleaner code and less power to unexperienced users, less need for var= and printVar=, less FLEs, etc, etc

2) mak:test would have an OQL expression (essentially an enhanced mak:value). that is not evaluated by JSTL, but by makumba (by the SQL engine in the end)

when i looked at JSTL i think i saw that it is possible to add one's own expression evaluator, but don't remember the details. also, JSTL comes in 2 versions: with java scripplet support and without... i'm not sure if the custom expression evaluator is possible for the scriplet support (older) JSTL. actuallly i think the expression language (EL) as such is only available in the non-scriplet JSTL version

so, question is: should we postpone this further until there is time to look more at JSTL OR implement it now and deprecate it later when JSTL support is added in makumba ?

about comment 3: i am really curious if the most common thing is notnull tests. any easy way to compile some sort of statistic about how many scriplets would this eliminate, and how many of them are null tests? in any case, i think it's time to start visiting the application (karamba) sources and derive some high-impact makumba changes

[ghost]

Comment by @cristianbogdan on 21 May 2003 07:29 UTC about comment 4 and comment 5: i definately think the long-term goal here is JSTL so i think that no matter we decide on the short term, somebody should look at JSTL/JSP2 and possibilities for support in makumba. Stefan? Fred?

also, the status of Tomcat 5 (to see how "long-term" this is) should be checked

[ghost]

Comment by @cristianbogdan on 21 May 2003 09:09 UTC about comment 3: in the current JSP taglib framework (that support scriplets), it is very hard to implement something like

... because you need to know at the begining of the tag whether the tag body will execute or not. if you support else, you will have to execute the mak:if even if the condition is false and ignore everything before mak:else. the problem is, if you execute when the condition is false, you will execute the scriplets inside, which may not be a logical thing to do (think that the scriplet can send an email which was meant to be sent only if the mak:if condition is true). take this as an example of "why scriplets are bad" there could be .... ... but again, this feature is provisional, short term and adding so many new tags is not consistent with that

[ghost]

Comment by @cristianbogdan on 21 May 2003 09:20 UTC it strikes me that it could be very useful to have something like a C (or Java) conditional expression test?expr1:expr2

imagine for example

$now"
onTrue="green" onFalse="red" />"

this can also be used to colorize mak:response (bug 442)

to avoid quote escaping i think this can be written (at least in JSP 2.0) like

some html some other html note that, in these cases, _both_ onTrue and onFalse will be evaluated, so having scriplets and makumba tags there needs be treated with caution.

[ghost]

Comment by @cristianbogdan on 27 Jun 2003 12:02 UTC implementation on top of 0.5.9 is pretty easy:

• TestTag extends MakumbaTag, declared in the TLD with an "expr" attribute
• doStartAnalyze initiates a ValueComputer from the expr attribute like ValueTag does
• doMakumbaStartTag reads the value (like in FormTagBase) then, if it is notnull and not 0, return EVAL_BODY_INCLUDE, else SKIP_BODY

niceties like onTrue=, onFalse=, can be added afterwards

mak:else can simply be executed if the last mak:test was not executed (that's easy to keep in a special pageContext attribute), so it can look like

<mak:test ....> .... </mak:test> blabla .....</mak:else>

the page analyzer could check if the middle blabla is empty, etc

about JSTL (comment 4): i think the present JSP parser can easily be used to translate all mak:tests into JSTL if's later on, when the makumba evaluator can be used to evaluate EL expressions :)

[ghost]

Comment by @cristianbogdan on 12 Sep 2003 13:17 UTC Ovidiu needs this feature in his work, I guess he's done enough for BEST IT to get it fixed soon :)

[ghost]

Comment by @frederikhabils on 12 Sep 2003 13:31 UTC this interests me (I voted for this a while ago ;) ), but I'm not so sure about the design so far.

At work, I'm starting on learning a perl-based templating language with tags, where the syntax is (essentially) this :

and also

You could stick mak: to that, and personally, I prefer this general design.

I think it also solves abovementioned issues with "both then/else need to be evaluated" and other "jsp doesn't support this" problems (comment 7, comment 8). It doesn't seem to answer the abovementioned concern "let's add only the strictest minimum number of tags".

[ghost]

Comment by @cristianbogdan on 12 Sep 2003 14:05 UTC at present i think having this feature is more important than its particular details (especially if JSTL will be the final design anyway)

i propose to go on with

and add ifcase later on, when needed.

what happens with the content inside that is not inside or ? should it give a page validation error? should it be simply shown in all cases (that's easier to implement) ? some ppl may want it to be shown if the expression is true (as if it were inside ) but that's pretty hard to do.

on the other hand " by default" can be easily done:

...

the only needs to know if it has a or (it can find out during page analysis) and if not, simply not show anything if the expression is false. we could add this as an extra feature if it proves useful.

i hope we agree on design now. if somebody wants to take this, please assign it before monday (when i have some time for it). i'll be glad to answer questions.

[ghost]

Comment by @frederikhabils on 12 Sep 2003 14:11 UTC If you like the previous idea, you can easily extend it a bit further:

where the logical (?) rule could be that if attribute then and/or else is defined, then the body of the element is skipped, whatever is inside.

The long form would be

this is true statement this is false statement I wonder if we should allow CDATA in the body, like this this statement is true false and that is good bad I guess that is very general, and general is good :-) Not that I expect such case as the last example, to be heavily used. Note: implementation should allow nested mak:if tags.

[ghost]

Comment by @frederikhabils on 12 Sep 2003 15:23 UTC mmm, damnit,

I just did some field research, into JSTL (java standard tag library) and XSL (for transforming XML to ...). These are 2 significantly important XML based tag languages, that are certainly good references & examples.

And they both have the same approach for this issue :

(== you'll have to repair this link! ==) http://www.informit.com/isapi/product_id~%7B0F6D267D-A165-49C8-B0EF- B84E7534713B%7D/element_id~%7B332C2FA7-C2E5-4500-A22B-79AE4ED51B08%7D/st~% 7B94C03A97-1188-4875-8A06-17743BA224B7%7D/content/articlex.asp

<c:if test="testCondition" [scope="..."> ... body content ... </c:if>

... One ... ... Two ... ... else body ... -> for 'choose' : only the content inside the when/otherwise is printed, no content allowed at root of choose tag. Also, the choose element ends at the first 'when' that matches. So even if 2 conditions match, only the first body is executed. ------- see : http://www.w3schools.com/xsl/ ... some code ... ... some code ... ... some code .... some output ... I hate to be so influencable, but maybe we should look at these big(ger) brothers? It will also simplify possible change to JSTL, if ever the case. Aaargh :-/

[ghost]

Comment by @stefanb on 12 Sep 2003 15:44 UTC In comment 4 i said:

Reinventing a standard taglib should only be done if there is no other (easy) way to use makumba data in test/if/choose/when/otherwise... expressions.

And i still firmly believe that trying to make use of makumba data from within JSTL tags shouold be tried before we introduce a new tag in a hurry.

[ghost]

Comment by @stefanb on 12 Sep 2003 16:07 UTC Ok, will try to be constructive :)

one idea would be to introduce "setParam" attribute to the tag that would set

Then it would be possible to use JSTL like:

Nice to see you around, ! :) Maybe not the most powerful example, but this would make it possible to use all the power of JSTL in makumba webapps. ...and there is plenty to gain. http://java.sun.com/products/jsp/jstl/ khm... "param.x" means Request parameter "x" as string. Maybe it would be better to not interfere with request parameters by setting new ones, and set Scoped variables from page scope... which brings me to a more flexible: as makumba alternative to JSTL set tag: Nice to see you around, ! :) A nice JSTL reference is at: http://www.manning.com/bayern/appendixA.pdf

[ghost]

Comment by @stefanb on 12 Sep 2003 16:28 UTC

Nice to see you around, ! :) was copy-pasted without too much thinking/fixing.

khm...it is even possible use it now:

Nice to see you around, ! :) but idea is the same :)

[ghost]

Comment by @frederikhabils on 12 Sep 2003 23:40 UTC [One of the most common tests, I presume, would be comparing to NULL. See bug 571, that doesn't seem to work right now.

2 Stefan wrote in comment 17

khm...it is even possible use it now:

Nice to see you around, ! :)

actually, the </c:set> can also be since this communication from tag to page, goes via attributes (in page scope, as chosen by VarTEI.java). In this manner, you do also create a java variable too, which you wouldn't need then. But it's shorter, and it exists :)

[3] because we've been going very general in this bug, we haven't done the most easy solution, for the most common case: print something instead of a blank, for NULL/blank data.

I added (not yet in CVS) a default="..." attribute to mak:value. It gets printed and/or stored in 'printVar', if the normal output would be a blank. Is just a few lines of code (see ~fred/dev/sources/makumba on tequila, if u'r fast)

Questions:

• do we want this (imo: yes)
• should the default-replacement happen only on null and not on blank (imo: no)
• ... or should this detail be configurable? (imo: not at this point)
• the replacement is coded in ValueComputer.java, at the print() method. Is that ok? (imo: dunno)
• none of the other behavioral attributes (like html, maxLength, ... ) have an impact on default (i.e., default text will not be html encoded, or cropped to shorter size, or urlEncoded). Is that ok? (imo: yes)

[ghost]

Comment by @frederikhabils on 13 Sep 2003 09:00 UTC i've created a branch out of makumba-0_5_9_10, called BR-0_5_9_10, on which I've committed my changes of comment 18.

(I prefer to make small, short-living branches for such unsure changes)

[ghost]

Comment by @stefanb on 13 Sep 2003 11:12 UTC was isolated in bug 572

A way to link makumba to jstl easily could be to find all instances of "mak.IDENTIFIER"s in JSTL tags (during page analysis) and set such variable in page scope, so that user doesn't need to write <mak:value expr="IDENTIFIER" var="..."/>, eg:

is

Fred, i separated mak:value default= into bug 572 and i think it should be fixed together with bug 501

about the choice mak:if/c:if, i think we have problems reaching a conclusion so i propose to simply support both and see what does better with the users. several reasons:

• the fact that c:if exists does not eliminate the argument for mak:if. i guess JSTL has loops too, do we want to give up mak:list, which is essentially a loop? JSTL has formatted output too (c:out), do we want to give up mak:value?

• unless bug 573 is fixed, a supplementary tag would be needed (even in the alternative, which btw will always receive the mak:value in HTML). according to my observations, that tag comes most unnatural for users. the transmission/conversion of values from makumba OQL to Java (or JSTL for that matter) is i think what makes it problematic and unnatural. also, in implementation terms, the expression of mak:if is evaluated directly in the DB, no need for translations to java, casting the type, check for null, etc.

• most of the time, in simple pages, a simple if is needed. no need for the other JSTL tags. it's not always worth going through the hassle of installing JSTL, learning it, etc, just for a simple if...

• it's very easy to implement mak:if so the cost is not that high. so it's easy to try out the idea.

so, if nobody objects strongly, i will implement mak:if on monday (together with fixing bug 571). also i will help implement any linking with JSTL may be needed to get a good integration (bug 573 and whatever else might pop up, to use <c:if and for other reasons)

[ghost]

Comment by @cristianbogdan on 13 Sep 2003 11:45 UTC (sorry for my API slip)

btw, in commnet 21 i refer to

....

[ghost]

Comment by @frederikhabils on 13 Sep 2003 11:53 UTC

so, if nobody objects strongly, i will implement mak:if on monday (together with fixing bug 571).

ok for me. Actually, I will try finding some time this weekend (but it's badly competing with other todos) for . Bug 571 is sth I'll more gladly leave to you.

[ghost]

Comment by farry@best.eu.org on 14 Sep 2003 13:04 UTC Cristi wrote (comment 21): about the choice mak:if/c:if, i think we have problems reaching a conclusion so i propose to simply support both and see what does better with the users. several reasons:

• the fact that c:if exists does not eliminate the argument for mak:if. i guess JSTL has loops too, do we want to give up mak:list, which is essentially a loop? JSTL has formatted output too (c:out), do we want to give up mak:value?

As mak-user I would prefer mak:if instead of c:if, just to have as much conformism between tags... I'm just thinking of a makumba training where you have to explain to new users: if you want to create a list, use 'mak:list', ha, and you can also make conditional statement, and for that you have to use 'c:if'... it's more easy to grasp for a new user if all tags are mak:something. (imho) (the only type of new users the would gain by having c:if, is the one having JSTL knowledge...)

[ghost]

Comment by farry@best.eu.org on 14 Sep 2003 13:05 UTC grmbl... don't know how to make links in bug reports yet... will look in the manual, so sorry for -tag in previous post...

Comment by @frederikhabils on 14 Sep 2003 16:46 UTC I've added support for mak:if on branch BR-0_5_9_10

classes/org/makumba/view/jsptaglib/IfTag.java; new revision: 1.1.2.1; classes/org/makumba/view/jsptaglib/MakumbaJspAnalyzer.java; revision: 2.3.2.1; servlet_context/WEB-INF/makumba.tld; revision: 2.5.2.2;

it's very basic, and does only this:

jsp stuff to do/show/print/execute if true expression Comments: - expr="..." can be any test expression (i.e. with boolean result 0/1) that would be allowed in a mak:value. Some test are not working (see bug 571, bug 574, bug 575 => no comparison with NIL, no comparison to a constant date). - there are no var=... and printVar=... . What would be their meaning, anyway? var=... could set a java.lang.Boolean. It doesn't seem necessary. - i've tested successfully with some comparison types, but did not try all possible variations. - other design extensions?

[ghost]

Comment by @cristianbogdan on 18 Sep 2003 10:35 UTC good work Fred!

as a minor improvement, i think one needs to check whether the OQL type of the expression is int (and maybe also only allow 1 and 0 values, to require code clarity)

maybe mak:choose would be an improvement in order not to write the test expression twice if you want if/else

also, i think we could have mak:if test=... (instead of expr=) in order to gain from familiarity makumba<->JSTL

[ghost]

Comment by @frederikhabils on 21 Sep 2003 10:39 UTC re comment 27. I've added a type check on the resulting value. It could be that you meant another type of type check, like on the OQL type. I'm not familiar with the options there.

I dropped expr=... and added test=...

all this is in 0.5.9.13.

[ghost]

Comment by @cristianbogdan on 21 Sep 2003 11:59 UTC some type analysis can be done at page analysis time, to make sure the if expression has an int type. i guess checking in doEndAnalyze() vc.type.getDataType().equals("int") does the trick, but one has to try :). a programmer-friendly error can be thrown (MakumbaJSPException or so), so a nice error message will be shown at analysis time. of course, the value check is still needed at runtime (though after succesful page analysis we know for sure that instanceof Integer will be true)

[ghost]

Comment by @frederikhabils on 18 Jan 2004 16:39 UTC I had some old modification in my local makumba checkout, that implements the idea of comment 29. I committed it now.

I found it problemmatic to throw the most appropriate Exception type: MakumbaJSPException (or so), shows the nices error message, but was not allowed to be thrown without changing the method's throws clause in the definition (also in super classes)

Instead I threw a ProgrammerError (or so). Maybe that was the lazy approach, and method definition (throws clause) should actually be changed?

[ghost]

Comment by @cristianbogdan on 18 Jan 2004 17:00 UTC I think ProgrammerError is ok if it shows an intelligible message to the user.

as for the throws clause, it doesn't need to be changed for errors, only for exceptions (we can continue this discussion by mail)

are we ready to close this?

[ghost]

Comment by @cristianbogdan on 28 May 2004 12:56 UTC i reviewed this a bit and we seem to be done with it, in the sense that the minimum necessary is there. if more is needed, we can reopen it with another target milestone (0.7, whatever)