content to show if a mak:list will have results

[ghost]

Reported by @cristianbogdan on 3 May 2010 09:31 UTC sometimes we want to show something only if a mak:list or some other query-dependent tag will have results.

the classical case is the table header row

currently this is done in the mak:list by checking whether we are at the first iteration. this is unnatural and unintuitive because the content is not produced at the place where it is actually shown, before the mak:list. it also creates issues with opening and closing tags in JSP editors, etc.

there were two generations of solutions to this issue. the first was countVar attribute of mak:list, currently deprecated. the second is the current one, mak:count() function, which is simply a function version of the first

however, page analysis (which was not so good at countVar times) gives us the possibility to have something like

content ... a more precise version could use id= to identify the mak:list but the page analysis can detect the mak:list for which the preamble is meant by proximity. there are two ways to implement this: - the preamble can abduct the query of the mak:list and execute it to see whether there will be results. - the preamble executes, retains its content and the lists prints the content if there are results. this is easier, but it leaves the problem that if there is content between the preamble and the list, it will be shown before the preamble a way to address the problem above (for both preamble and postamble) is to only support an envelope preamble ... postamble the other idea is to support this in function form preamble ... if feels quite natural to actually use the mak:list id, rather than just proximity to the mak:list preamble ... postamble still to implement this in a general function-style way, one needs to abduct the query and detect functions at page analysis (which is also needed for bug 1055). note that the same function form can be used after the query, for postamble, i.e. the hasContent() will be guaranteed to execute the query only once. about query abduction, do note that non-root mak:lists don't actually produce queries, but just do a check in the grouper of the root query. so it's not that hasContent will always execute queries. also, this also shows that the following is illegal, because an embedded list might have or not have content, depending on the iteration of the root list ${"... hasContent('embeddedId') ..."} .... on the other hand this is ok ${"... hasContent('embeddedId') ..."} .... Migrated-From: http://trac.makumba.org/ticket/1206

[ghost]

Comment by @rudolfmayer on 3 May 2010 18:43 UTC (In reply to comment #0)

the other idea is to support this in function form

preamble ...

to keep the naming scheme we have at the moment, namely mak:count(), mak:maxCount(), and especially mak:lastCount(), I'd call this mak:nextCount().

if feels quite natural to actually use the mak:list id, rather than just proximity to the mak:list

Adding the ID or not is I guess the same issue as with the preamble tag.

Also, if the ID is added, mandatory or optional, this should be equivalent in mak:lastCount()

[ghost]

Comment by @cristianbogdan on 3 May 2010 20:44 UTC (In reply to comment #1)

to keep the naming scheme we have at the moment, namely mak:count(), mak:maxCount(), and especially mak:lastCount(), I'd call this mak:nextCount().

Adding the ID or not is I guess the same issue as with the preamble tag.

technically yes but the tag will almost always be near the mak:list while the function can really be anywhere.

also i think nextCount() is easier to implement with id than without because it needs no page analysis. but at some point we will have to add functions to page analysis anyway.

btw, what happens if nextCount() is called after the list? for root mak:lists, that's 0 probably (i guess we don't want to execute the queries again??). for non-root, could give you the list count for the next iteration of the containing list

Also, if the ID is added, mandatory or optional, this should be equivalent in mak:lastCount()

yes we could add the ID for all count functions. i think there is anyway a request to identify the list for one of them ?

[ghost]

Comment by @rudolfmayer on 3 May 2010 23:12 UTC (In reply to comment #2)

(In reply to comment #1)

to keep the naming scheme we have at the moment, namely mak:count(), mak:maxCount(), and especially mak:lastCount(), I'd call this mak:nextCount().

Adding the ID or not is I guess the same issue as with the preamble tag.

technically yes but the tag will almost always be near the mak:list while the function can really be anywhere.

If this assumption is correct, then it is much of an argument to provide only the mak:nextCount() function, which gives more flexibility, and at the same time limits the number of new tags needed to be learned, thus prevent Makumba from getting bloated (see e.g. http://www.javalobby.org/java/forums/m92069311.html for a nice thought about such issues in Java)

also i think nextCount() is easier to implement with id than without because it needs no page analysis. but at some point we will have to add functions to page analysis anyway.

That is partly done since last week; used only in the JSP viewer till now, though.

btw, what happens if nextCount() is called after the list? for root mak:lists, that's 0 probably (i guess we don't want to execute the queries again??). for non-root, could give you the list count for the next iteration of the containing list

The behaviour should be similar to the other functions, see http://bugs.makumba.org/show_bug.cgi?id=983

As such, I think that mak:nextCount(), with no mak:list after it, should throw a programmer error.

[ghost]

Comment by @cristianbogdan on 4 May 2010 09:35 UTC (In reply to comment #3)

If this assumption is correct, then it is much of an argument to provide only the mak:nextCount() function, which gives more flexibility, and at the same

i don't care really, let's focus just on functions for now, and we can see whether it makes sense to "distill" the functionality further into a tag. that said, see the end of the comment for more comments :)

That is partly done since last week; used only in the JSP viewer till now, though.

seeing the function syntactically is a good first step. analyzing semantically looks 'easy'. the runtime situation is a bit more challenging because EL functions are basically statics. at runtime they need to grab the mak:list runtime data from some threadlocal, execute its abducted queries if needed, etc.

The behaviour should be similar to the other functions, see http://bugs.makumba.org/show_bug.cgi?id=983

As such, I think that mak:nextCount(), with no mak:list after it, should throw a programmer error.

yes. or if there is no mak:list with the indicated id.

but, for non-root mak:lists:

• it does make sense to have a lastCount before the list, and a nextCount after the list because they would give results from the previous/next iteration of the enclosing list. this can be generalized to root lists, they will simply return 0 or -1 (like lastCount before any execution of its list)
• i don't think it make sense to have lastCount/nextCount inside their own list. that would again (like above) refer to the previous iteration of the enclosing list. not sure.
• i don't think it makes sense to have a nextCount or lastCount for a list outside its parent list. see the ${"... hasContent('embeddedId') ..."} example in comment 0. this is similar to bug 983, having a count() outside any list or a count(id) outside the list with that id.

so (if we don't allow them inside their list) it seems that lastCount and nextCount have to be _at_the_same_listlevel with the list they refer to, whether it is a root or non-root list. this actually means that they will most often need no id, because they will always refer to the adjacent list (above or below). it only makes sense to use an id when there are more lists at the same level and you want to distinguish between them.

it does make sense to use id for count() and maxCount() i think, especially (or only?) if they refer to a parent list (or the enclosing list which is equivalent to no id), not to a child list.

/* on the tag vs function discussion:

my main concern is to bring better page structure. nextCount is clearly needed for that but i think envelope creates a cleaner page

a search in karamba reveals that lastCount() is most often compared to zero (somewhat equivalent to envelope). when it is not, it seems to be used as a replacement for MQL count(), which might not be used much due to lack of sub-queries

i also find it unnatural to provide a count when i will most often be interested on whether there will be (or whether there were) elements. java has both isEmpty() and size() :) (for me that's not bloating, but add() and addElement() is :) )

anyway in design there are many right answers. the bloating argument is interesting but i think we are far away from that :) the more iterating approach is to let more things fly for a while and see how they are used in practice. */

[ghost]

Comment by @rudolfmayer on 4 May 2010 16:43 UTC Some initial thoughts about implementation of mak:nextCount()

*** the flow should be something like this 1.) in the nextCount() function, retrieve the request 2.) from the request, get the pageCache 3.) from the pageCache, get the next QueryTag 4.) tell the query tag to execute it's query, and to set a request attribute for the result 5.) then in the function, retrieve that attribute and return it

The following issues appear 1.) We need the ServletRequest; that gets set by the QueryTag in the field servletRequestThreadLocal during doAnalyzedStartTag; this is after nextCount() is run. Interestingly, on a second loading of the page, the servletRequestThreadLocal is set

2.) Seems to be fine.

3.) would be fine, if we'd have any information in the function from where we actually get executed.. So, with not knowing which nextCount() function in the page I am, I can't retrieve the next QueryTag Easy solution: as mentioned, providing the ID to the function, and then retrieve the right tag by the ID

So, with having the ID passed on, I could make a nextCount() function that has an infamous first-load-error :-)

Thus, any advice appreciated....

[ghost]

Comment by @cristianbogdan on 4 May 2010 17:59 UTC about problem (1) QueryTag.servletRequestThreadLocal was designed only for things that make sense inside or after the list tag. but nothing prevents you to move/copy it in some makumba filter and set it before the page begins execution. as it is now, it's set when the first QueryTag begins execution, which may be too late.

why it works at second load, i have no clue... maybe it's not reset from the first :)

about problem (3) that's indeed a showstopper for lots of function ideas. basically tags find themselves via their attributes. but since functions have no attributes, it makes it hard.

the way we avoided this up to now is that tags put up things where functions can find them, whether there is a function that needs them or not. maybe this can save the idea of mak:value(expr) (bug 1055)

but nextCount() is special because it comes before its tag. however, i think nextCount with no id should be illegal if you have more than one mak:list at that level

mak:list mak:list /mak:list nextCount() mak:list /mak:list /mak:list which mak:list does the nextCount() refer to? it makes sense to have nextCount for both. so you need an explicit id.

but if you have only one mak:list at that level, are u able to find it in the cache? like

nextCount() mak:list /mak:list

and

mak:list nextCount() mak:list /mak:list /mak:list

[ghost]

Comment by @rudolfmayer on 4 May 2010 18:40 UTC (In reply to comment #6)

about problem (1) QueryTag.servletRequestThreadLocal was designed only for things that make sense inside or after the list tag. but nothing prevents you to move/copy it in some makumba filter and set it before the page begins execution. as it is now, it's set when the first QueryTag begins execution, which may be too late.

Indeed, I thought initially that the thing is specific for a QueryTag, but it is not, actually. So yes, setting it from the ControllerFilter makes sense.

However, some more modifications are needed then, cause some parts of the query execution now require a pageContext, which we don't have in the function, nor in the filter.

about problem (3) that's indeed a showstopper for lots of function ideas. basically tags find themselves via their attributes. but since functions have no attributes, it makes it hard.

the way we avoided this up to now is that tags put up things where functions can find them, whether there is a function that needs them or not. maybe this can save the idea of mak:value(expr) (bug 1055)

I think that mak:value("expr") can still work. As I understand:

• during analysis, we need to add the projection to the enclosing mak:list. That should be no problem.
• when running, the function knows what it's expression is from the parameter. So, it could find the evaluated value for it from the request attributes (where the list has put it)

but not specific to this bug entry :-)

but nextCount() is special because it comes before its tag. however, i think nextCount with no id should be illegal if you have more than one mak:list at that level

mak:list mak:list /mak:list nextCount() mak:list /mak:list /mak:list which mak:list does the nextCount() refer to? it makes sense to have nextCount for both. so you need an explicit id.

To me, it refers to the exactly next mak:list, so not that difficult to figure out. in the example you posted, after the nextCount() there is exactly one opening mak:list anyhow; it could never refer to the outmost enclosing list, and the fist nested list is already closed.

but if you have only one mak:list at that level, are u able to find it in the cache? like

well, directly, I can only find the right list if it is the only list in the page.

To solve thoi, I think once can do something like this:

• in analysis, store an ordered list of all mak:lists that have a preceeding mak:nextCount() (if there is more than one nextCount() before a list, just add that list n times)

• during execution, keep a request attribute that stores the count of which mak:nextCount() we are at

• retrieve the querytag from the list, and then increment the counter

[ghost]

Comment by @cristianbogdan on 4 May 2010 19:56 UTC (In reply to comment #7)

Indeed, I thought initially that the thing is specific for a QueryTag, but it is not, actually. So yes, setting it from the ControllerFilter makes sense.

However, some more modifications are needed then, cause some parts of the query execution now require a pageContext, which we don't have in the function, nor in the filter.

not having a pageContext sucks. and JSP design sucks i mean they could pass the damn page context when they invoke the function. anyway.

also, analysis is done at first makumba tag to what i remember. that means that if the function comes before any mak tag, it's screwed anyway.

if not, the first makumba tag can put the pageContext in the ThreadLocal

also AnalysableElement hangs things on ThreadLocals like crazy.

some alternatives to the current situation:

• put analysis on the request, not on the pageContext.
• it may be possible to detect from the filter when the request includes/forwards to another page
• if that's possible, we probably can trigger analysis in the filter, not at first mak tag. we trigger it for the page in request URI and for all the pages it includes/forwards

I think that mak:value("expr") can still work. As I understand: yes that's what i meant

mak:list mak:list /mak:list nextCount() mak:list /mak:list /mak:list which mak:list does the nextCount() refer to? it makes sense to have nextCount for both. so you need an explicit id.

To me, it refers to the exactly next mak:list, so not that difficult to figure out.

yes but technically nextCount() after the mak:list does make sense. so in the above you prioritize one mak:list over the other. in any case, you stand little chance to find which nextCount() you are. like here:

nextCount() mak:list /mak:list nextCount() mak:list /mak:list

you will not know in which of the nextCounts you are, and therefore you will not know what mak:list to deal with.

at least if you say that you don't allow id-less nextCount() if you have more than one mak:list at that level, you solved this problem.

well, directly, I can only find the right list if it is the only list in the page.

not really because you also know which mak:list are in the course of being executed (you can hang the key of that in the request). from the key of the lists, you know which mak:lists are sublists of that. if it has only one, you know it's that one.

• in analysis, store an ordered list of all mak:lists that have a preceeding mak:nextCount() (if there is more than one nextCount() before a list, just add that list n times)

• during execution, keep a request attribute that stores the count of which mak:nextCount() we are at

• retrieve the querytag from the list, and then increment the counter

this works great if you don't have java code that jumps back to a certain nextCount()

also, if you have a nextCount inside a mak:list, that will repeat. so things don't just flow linearly

---

one other thing that may help is that you can find where you are in the page from a stacktrace. at least you can e.g. find out that you've been at this nextCount() before so you don't increment your counter.

finding the JSP line from the stacktrace is highly dependent on the java code generated by the JSP compiler. otherwise we would have used this info to identify tags at runtime, not the tag attributes.

but it may be worth doing it anyway. a stacktrace in QueryTag looks like

at org.makumba.list.tags.QueryTag.doAnalyzedStartTag(QueryTag.java:290)
at org.makumba.analyser.AnalysableTag.doStartTag(AnalysableTag.java:218)
at org.makumba.commons.tags.GenericMakumbaTag.doStartTag(GenericMakumbaTag.java:45)
at org.apache.jsp.index_jsp._jspx_meth_mak_005flist_005f0(index_jsp.java:893)
at org.apache.jsp.index_jsp._jspx_meth_mak_005finput_005f1(index_jsp.java:829)
at org.apache.jsp.index_jsp._jspx_meth_mak_005fform_005f0(index_jsp.java:737)
at org.apache.jsp.index_jsp._jspService(index_jsp.java:274)

from the stacktrace i see that this mak:list is called mak_005flist_005f0 and if i search for that in the java source i find _jspx_th_mak_005flist_005f0.setFrom("dox.Parte dp");

and above that i see a comment // /index.jsp(73,0) name = from type = java.lang.String reqTime = false required = true fra\ gment = false deferredValue = false expectedTypeName = null deferredMethod = false methodSignat\ ure = null

so i know i am at line 73 in my JSP :))) column 0!

but if i do this for a function i get

at org.makumba.list.tags.QueryTag.lastCount(QueryTag.java:587)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.el.parser.AstFunction.getValue(AstFunction.java:110)
at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:935)
at org.apache.jsp.index_jsp._jspx_meth_mak_005fform_005f0(index_jsp.java:747)
at org.apache.jsp.index_jsp._jspService(index_jsp.java:280)

and i know i'm in a form and i can find out what the form is (like i found the list above)... i'm not in any of the form inputs, not in any subtag of the form. unfortunately there are no good comments for functions...

so if there are more functions in that form, i'm lost again. if they are executed in page order, i can figure out from the line number (747) which is first, which is second, etc.

[ghost]

Comment by @cristianbogdan on 4 May 2010 20:11 UTC given these funny complexities you may want to implement nextCount() only with id. even so, you have the problems with finding the analysis and the QueryTag runtime

(In reply to comment #8)

and i know i'm in a form and i can find out what the form is (like i found the list above)... i'm not in any of the form inputs, not in any subtag of the form. unfortunately there are no good comments for functions...

so if there are more functions in that form, i'm lost again. if they are executed in page order, i can figure out from the line number (747) which is first, which is second, etc.

actually, given the JSP line of my mak:lists (which i get at analysis), i can figure out the Java line of each mak:list start. therefore i should be able to figure out which mak:list the current function refers to.

but of course i only need this if i have id-less functions.

it was a fun problem anyway :)

[ghost]

Comment by @rudolfmayer on 4 May 2010 21:55 UTC (In reply to comment #8)

some alternatives to the current situation:

• put analysis on the request, not on the pageContext.

I am not sure if that couldn't cause any side-effects ... let's say if there are pages jsp:included, then they had their own pageContext, and now, they would share the same request => could lead to some collissions.

mak:list mak:list /mak:list nextCount() mak:list /mak:list /mak:list which mak:list does the nextCount() refer to? it makes sense to have nextCount for both. so you need an explicit id.

To me, it refers to the exactly next mak:list, so not that difficult to figure out.

yes but technically nextCount() after the mak:list does make sense.

I don't think that mak:nextCount() makes sense after a mak:list (for that, you'd use mak:lastCount() anyhow)

imho,

• if I am after a list, there can't be a nextCount() for it
• if I am in a mak:list, the nextCount() can only refer to the next nested mak:list

but actually, if you use the id of a mak:list as param, one could use mak:maxCount('id') for both the nextCount() and lastCount(), and use mak:maxCount() w/o any parameter just as now for the enclosing mak:list

that might be a nice design (that is, if function overloading is ok in EL functions...)

one other thing that may help is that you can find where you are in the page from a stacktrace. at least you can e.g. find out that you've been at this nextCount() before so you don't increment your counter.

I thought about that as well while being in the debugger mode (eclipse debugger even tells you the JSP file and line number already :-), but this seems really like a hack... so, if we do this, maybe only in a version 2.0 of the feature :-)

[ghost]

Comment by @rudolfmayer on 4 May 2010 22:02 UTC (In reply to comment #10)

(In reply to comment #8)

some alternatives to the current situation:

• put analysis on the request, not on the pageContext.

I am not sure if that couldn't cause any side-effects ... let's say if there are pages jsp:included, then they had their own pageContext, and now, they would share the same request => could lead to some collissions.

Taking a quick glance, the QueryTag triggers a QueryExectuion, which itself relies on a PageAttributes Object...

=> i.e. replacing pageContext with request means replacing it in a hell lot of places ... !

[ghost]

Comment by @cristianbogdan on 4 May 2010 22:44 UTC (In reply to comment #10)

(In reply to comment #8)

some alternatives to the current situation:

• put analysis on the request, not on the pageContext.

I am not sure if that couldn't cause any side-effects ... let's say if there are pages jsp:included, then they had their own pageContext, and now, they would share the same request => could lead to some collissions.

well AnalysableElement makes a stack in thread locals and i think it makes it precisely for this reason. not sure.

in any case you can solve inclusion with a stack.

the problem is to detect inclusion and be able to run mak code when inclusion takes place.

---

comment 11:

Taking a quick glance, the QueryTag triggers a QueryExectuion, which itself relies on a PageAttributes Object...

=> i.e. replacing pageContext with request means replacing it in a hell lot of places ... !

i don't think that's a big problem. we have automated tests remember? :) we only need to add some with jsp:include :)

since you can get the request from any pageContext but not the other way around, finding and passing the request should be ok (with the stack reservation above)

triggering page analysis before first makumba tag (and detecting include to be able to analyze the included page) is the problem for me still. without that, it seems hard to provide any pre-tag function.

or maybe you want a tag instead? :) :)

i hope i remember right that it was the include problem that lead me trigger the analysis at first makumba tag instead. but it's worth a try i guess.

we could simply say that we don't supprt jsp:include at all :)

I don't think that mak:nextCount() makes sense after a mak:list (for that, you'd use mak:lastCount() anyhow)

they are different (see comment 2 :) ). nextCount after a mak:list tells you how many elements the mak:list will have for the next iteration of its parent mak:list (if any)

so technically yes it makes sense, and we have the data for it. whether we support it or not, that's another story.

but actually, if you use the id of a mak:list as param, one could use mak:maxCount('id') for both the nextCount() and lastCount(), and use mak:maxCount() w/o any parameter just as now for the enclosing mak:list

i thought of that too but then i thought that nextCount and lastCount after a list (and conversely lastCount and nextCount before a list) are technically different things so i would not replace them with just count.

also i think count should mean current iteration and nothing more.

I thought about that as well while being in the debugger mode (eclipse debugger even tells you the JSP file and line number already :-), but this seems really like a hack...

i wonder how it does that. if we find that out (i.e. dig into the WTP code), we have a much better runtime for both functions and tags.

so, if we do this, maybe only in a version 2.0 of the feature :-)

well, all this probably makes little sense for JSF...

[ghost]

Comment by @rudolfmayer on 4 May 2010 23:09 UTC (In reply to comment #12)

I don't think that mak:nextCount() makes sense after a mak:list (for that, you'd use mak:lastCount() anyhow)

they are different (see comment 2 :) ). nextCount after a mak:list tells you how many elements the mak:list will have for the next iteration of its parent mak:list (if any)

I don't think that this is intuitive at all...

but, can you give me a use case when you would need to use this?

but actually, if you use the id of a mak:list as param, one could use mak:maxCount('id') for both the nextCount() and lastCount(), and use mak:maxCount() w/o any parameter just as now for the enclosing mak:list

i thought of that too but then i thought that nextCount and lastCount after a list (and conversely lastCount and nextCount before a list) are technically different things so i would not replace them with just count.

also i think count should mean current iteration and nothing more.

mak:count() is the current iteration, yes. I said mak:maxCount() (rather it should be called totalCount(), but that is a different story), which inside a list gives you the total number of iterations this list has.

so, it is giving you the exact same information as lastCount() and nextCount(), and the only difference between the functions is that their name defines the place where they can be used.

adding an ID to lastCount() and nextCount() seems logical anyhow (to not need to store values for later usage in a page), thus the id to unify.

[ghost]

Comment by @cristianbogdan on 5 May 2010 08:22 UTC (In reply to comment #13)

but, can you give me a use case when you would need to use this?

no. i just know that we have the data for it, in the grouper.

also since the principle is that functions can be used everywhere, i don't see why a function/functionality should not be accessible in some unnatural place

like String,indexOf returns you -1 for something that is not applicable and that may seem unnatural but it becomes perfectly natural when you want to add 1 to find the next character and that becomes the beginning of the string... (0)

mak:count() is the current iteration, yes. I said mak:maxCount() (rather it should be called totalCount(), but that is a different story), which inside a list gives you the total number of iterations this list has.

sorry about count(). but even maxCount() is now only supposed to work inside the list right? i wonder why we introduced lastCount if maxCount was supposed to return the same result?

actually count should be called index or listIndex or listCounter or so? i think i was too focused on counting when this came about.

---

anyway, i wanted to put the unnatural idea through, just in case you as user representative :) thought it's interesting. but that doesn't seem to be the case so maxCount() or totalCount() all over the place is ok for me.

adding an ID to lastCount() and nextCount() seems logical anyhow (to not need to store values for later usage in a page), thus the id to unify.

well you need to add it also because it's damn hard to implement without :)

[ghost]

Comment by @cristianbogdan on 5 May 2010 08:26 UTC about the analysis issues. my major discovery for the day:

http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/jsp/JspFactory.html

you can basically reset the JSPFactory to a factory of your own. all methods of JSPFactory are abstract public so they can be wrapped.

i've just tested calling JspFactory.setDefaultFactory(JspFactory.getDefaultFactory()); from makumba, and it works. which means that we have the right to reset the jsp factory.

therefore, on getPageContext(), we can return what the original factory returns, but hang that object in the threadLocal stack, and maybe do more...

on releasePageContext(), we pop it from the stack

getPageContext and releasePageContext also tell you when an include begins and ends. so you maybe can trigger page analysis on getPageContext, i.e. before the page begins.

therefore no matter where the function is, you can have pageContext and also analysis! in a servlet engine independent manner! well some servlet engines may not accept reseting the JspFactory but tomcat seems to do so.

i think we could use this opportunity and start (or at least not hinder) supporting jsp:include in mak:list (bug 1048). like provide a link to the parent (including) page from a custom pageContext

---

i checked and eclipse knows the JSP line number even if you put a breakpoint in e.g. QueryTag.lastCount() (i.e. a function rather than a tag). this is a bit frustrating, i've no clue how they do it :)

[ghost]

Comment by @rudolfmayer on 5 May 2010 09:04 UTC (In reply to comment #15)

i checked and eclipse knows the JSP line number even if you put a breakpoint in e.g. QueryTag.lastCount() (i.e. a function rather than a tag). this is a bit frustrating, i've no clue how they do it :)

Yes, they know how to do that, but even better:

• you can put breakpoints in the jsp, and
• you can go step by step through the JSP as well (you see how the mak:list iterates... !)

I would assume they do what you talked about, matching back the stacktrace & the JSP generated source to find the original place in the JSP

[ghost]

Comment by @rudolfmayer on 5 May 2010 23:23 UTC

I don't think that mak:nextCount() makes sense after a mak:list (for that, you'd use mak:lastCount() anyhow)

they are different (see comment 2 :) ). nextCount after a mak:list tells you how many elements the mak:list will have for the next iteration of its parent mak:list (if any)

I guess lastCount() indeed analogously now, if put inside a root mak:list, and before a nested list, the result of the last time the inner list was run. still, doesn't seem that logical to me, and tricky to achieve.

(In reply to comment #14)

mak:count() is the current iteration, yes. I said mak:maxCount() (rather it should be called totalCount(), but that is a different story), which inside a list gives you the total number of iterations this list has.

sorry about count(). but even maxCount() is now only supposed to work inside the list right? i wonder why we introduced lastCount if maxCount was supposed to return the same result?

yes, maxCount() works only inside a list, that is the only difference for the usage (implementation wise, they are different, as one has the data from the list tag, and the other uses a request variable)

actually count should be called index or listIndex or listCounter or so? i think i was too focused on counting when this came about.

in JSTL loops you can make a "status" object, and that status object has index, count, and also a boolean first & last.

index seems very natural from programming language terms also. and count() or totalCount() for actually the total number of iterations seems also better..

[ghost]

Comment by @rudolfmayer on 6 May 2010 21:17 UTC mak:nextCount() is implemented by http://makumba.svn.sourceforge.net/makumba/?rev=4944&view=rev

The implementation is at the moment w/o being able to pass the ID, and using heuristics to find the next mak:list.

the tests in http://makumba.svn.sourceforge.net/makumba/?rev=4945&view=rev illustrate some example uses.

The suggestion of comment 2, to have next:count() after a nested lists mean the next iteration of the nested list is not yet supported.

[ghost]

Modified by @manuelbernhardt on 28 Jun 2010 07:22 UTC

[ghost]

Modified by @manuelbernhardt on 28 Jun 2010 07:24 UTC

[ghost]

Modified by @manuelbernhardt on 28 Jun 2010 07:36 UTC

[ghost]

Comment by @cristianbogdan on 19 Mar 2013 01:38 UTC most ideas seem implemented so i close this