Re: [Makumba-user] new mak:listGroup feature

[Cristian B. <cr...@cs...>]

Hi, old thread :)

I need to implement in HTML (which has no c:if and I want to avoid implementing 
hasValueChanged there if I can, as well as do c:if with <div data-visible="expr" >)

<div data-groupOn="expr">...</div>

so to test the idea, I replaced my old hack (which was not generic enough) with

<mak:listGroup on="expr" > ...</mak:listGroup>

which is the same as
<c:if test="${mak:hasValueChanged('expr')}">...</c:if>

I don't know how to do the equivalent of willValueChange in HTML, and I don't have a use 
case either...

best,

cristi

PS: on the other hand, the other mak:list "novelty"
<mak:list from="int i" where="i>=0 AND i<10" > ... </mak:list>

should work out of the box in HTML. I think even combining int with MDDs in the same 
mak:list works. Combining in other mak:lists surely works.

On 07/11/12 10:40, Cristian Bogdan wrote:
> Hi Rudi, great to hear from you!
>
> On 2012-11-07 09.28, Rudolf Mayer wrote:
>> Nice work! but I wonder, isn't that similar to what the
>> hasValueChanged() function would do?
>
> indeed but this is done in a UI-hierarchical way. Basically in the HTML/JSP/source tree
> you want the "grouping" element (customer) to be the "father" of the "grouped" element
> (sales data). I am not sure "group" is the best terminology here but that's another story
>
> I was thinking strategically in e.g. a graphical environment which does not necessarily
> produce HTML (consider the Swing thing I have done and recently published). There you
> can't affect the structure/hierarchy by way of c:if, and even if you could, it is good for
> the user to see the hierarchy directly in the "source". With hasValueChanged() this
> doesn't happen.
>
> best,
>
> cristi
>
>
>
>> On 6 November 2012 01:42, Cristian Bogdan <cr...@na...> wrote:
>>> Dear  makumba  users,
>>>
>>> I've  implemented <mak:list distinct="true"> the other day as  I needed it
>>>   in a  personal project.
>>>
>>> Say I have a Sales  table that  has a (string) field  customer. I  want to
>>> list the data in the table but I want to sort by customer and format the
>>> output nicely  for each  customer. There is no customer table (or there
>>> may be, but the customer name is repeated in the Sales table for query
>>> optimization reasons, i.e. the data is not in "normal  form", which often
>>> brings the need for using distinct)
>>>
>>> Using distinct=true
>>>
>>> <mak:list from="Sales c"  distinct="true">
>>>     nice  formatting <mak:value expr="c.customer" /> more formatting
>>>     <mak:list  from="Sales data"  where ="data.customer=c.customer">...show
>>> data...</mak:list>
>>> </mak:list>
>>>
>>> This is a performance disaster because
>>> - the table is joined unnecessarily with itself, for a large table this is
>>> unacceptable
>>> - the SELECT DISTINCT is slower because it needs  to examine all results
>>> and eliminate duplicates
>>>
>>> The other option  is  to do a single mak:list ordered by customer, and to
>>> use c:if to detect when the customer value changed from the previous
>>> mak:list iteration, and display the nice formatting then. This is much
>>> faster  (no join, no DISTINCT)  but  the code is ugly. Besides,  there are
>>> really two lists (one with customers, one with sales per customer) which
>>> are not visible in the code as nicely  embedded tags, as they are in the
>>> distinct version above.
>>>
>>> It is important that the code/tag hierarchy respects the user interface
>>> hierarchy,  and this is often provided by makumba.
>>>
>>> So I implemented this approach
>>>
>>> <mak:list from="Sales data"  orderby="data.customer">
>>>     nice  formatting <mak:value expr="data.customer" /> more formatting
>>>     <mak:listGroup>...show data...</mak:listGroup>
>>> </mak:list>
>>>
>>> Basically the listGroup will hide everything _outside_ it  (and inside the
>>> mak:list) unless one of the mak:values  outside it (and inside the
>>> mak:list)  changes value from the previous mak:list iteration. Currently
>>> this hiding is implemented via a HTML comment :).  More sophisticated
>>> implementation can be thought of (a special page writer that can be turned
>>> on and off), but this version is anyway thousands of times faster  than
>>> the DISTINCT version.
>>>
>>> Some more features:
>>> - it is possible to have a mak:list in a listGroup,
>>> - the mak:list  in a listGroup can contain listGroup in its turn
>>> - listGroup can declare a separator
>>> - a listGroup in a listGroup would make sense but it doesn't work yet
>>>
>>> As you can see, listGroup brings a list-like notation even if there is no
>>> separate table (two embedded iterations over the same table). There are
>>> more cases when the data that you want to list does not come from a table:
>>> sequences of numbers, date intervals, etc. Such small "data sources" could
>>> be easily integrated and "joined" with DB data
>>>
>>> all the best,
>>>
>>> cristi
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>>> Stay in control, update software, and manage PCs from one command center
>>> Diagnose problems and improve visibility into emerging IT issues
>>> Automate, monitor and manage. Do more in less time with Central
>>> http://p.sf.net/sfu/logmein12331_d2d
>>> _______________________________________________
>>> Makumba-user mailing list
>>> Mak...@li...
>>> https://lists.sourceforge.net/lists/listinfo/makumba-user
>>>
>