Hi Eric - thanks for this question, which I imagine is something comes up a lot. I guess it's best to start
with a few physical and philosophical points.... firstly, that the action of the renderer is to slap a large
markup string which it has carefully pre-formed, into the "innerHTML" of a DOM node. This is for performance
reasons, amongst others - even in modern browsers, long sequences of primitive DOM manipulations become a
serious performance risk, because of the global locks which each operation must take out. So, there is no
possibility for any DOM state and event handlers to survive this process since there is no "stripping"
process - the entire block of DOM state is destroyed and recreated.
This puts a premium on trying to work together with the renderer rather than trying to pick up its products
after the fact (although the latter approach could probably be made to work). Unfortunately the Pager is not
a fully baked component and doesn't expose quite all the workflow that you might be interested in - however,
I think you are at least partially in luck that the piece that you are interested probably exposes enough to
help you. In particular, the "fluid.pager.renderedPageList" component fires an event
events.onRenderPageLinks.fire(pageTree, newModel);
of which the first argument is actually the renderer's component tree for the upcoming operation of
rendering the page links area for the pager. It may not be perfectly obvious from the documentation, but
actually the implementor is warmly invited to process and modify this first argument (in place) to add any
additional material they require to the upcoming rendering activity. The "page links tooltip" component
actually uses this method in order to decorate the page links area with tooltips describing the ranges
covered by each of the pages - but there is no reason that you should add completely new components for
example dealing with the paycheck amount etc. (of course adding suitable extra markup to the template for
this area - it may require a bit of "fiddling" to make this interact nicely with the rather rigid hierarchy
required by the HTML table layout - give Jen a shout since she has done this and knows how).
Your second point is interesting and highlights an important design point underlying the Fluid components.
In general, we consider using the DOM itself as a source and repository of state (as in the case of your
checkbox) to be somewhat dangerous and undesirable - it takes a long time to train ourselves and our users
out of this habit because it is so prevalent in client-side programming. You will be familiar with the MVC
pattern from the server-side and we believe that it isn't just for Christmas... all of the components in the
Fluid set (except for those designed right at the start of the project and not yet reformed) keep a
well-defined "model" as a top-level member, holding the pure state which they will use for their rendering.
It would be a great exercise to convert your piece of functionality you describe into a Fluid component of
this type, and arrange to attach a listener from it to the event handler I mention above. Here are some
helpful links to get you started -
http://wiki.fluidproject.org/display/fluid/Fluid+Component+API
http://wiki.fluidproject.org/display/fluid/Getting+Started+Creating+Infusion+Components
http://wiki.fluidproject.org/display/fluid/How+to+Create+a+Fluid+Component
http://wiki.fluidproject.org/display/fluid/Component+Model+Interactions+and+API
(this one very old)
http://wiki.fluidproject.org/display/fluid/How+to+Define+a+Unit (the word "Unit" is no longer used, we
simply say "component" even though it is ambiguous)
Give us a shout on-list or in IRC if you need a hand - it isn't as daunting as
it looks
On 16/02/2011 19:08, Eric Dalquist wrote:
I keep running into this same problem and am hoping someone has a suggestion or
two. The problem is with the
pager it appears to strip all state and event handlers from all elements within
the pager div every time it
re-renders. In most cases I've been able to work around it but in this case I'm
not sure what to do. Our UI
design calls for two table header rows, one with a checkbox that lets the user
toggle if their paycheck
amount is visible and a second with the actual table headers. I attach a jQuery
event handler to the
checkbox using the live() function to deal with the fact that any time the user
sorts or pages normal event
handlers on the input are removed. The bigger problem is the state of the
checkbox is also reset. If the
user checks the box then pages or sorts the box unchecks. Is there some way to
get the renderer to not strip
state (and even better event handlers) from elements when it is redrawing the
page? Especially elements like
this which have no rsf:id attributes and have no real need to be touched by the
renderer code.
Another thing that would be useful that wasn't obvious from the docs is a
postRender() callback. That way I
could at least re-attach event handlers to all of the new elements when paging
or sorting happened instead
of using the live() feature of jQuery.
<div class="fl-pager">
<div class="fl-container-flex hrs-pager-table-data fl-pager-data">
<table class="hrs-table">
<thead>
<tr>
<th colspan="3" class="hrs-earnings-ammount-toggle">
<form action="#">
<input id="Pluto_35_n40_16_n40_hrs-earnings-ammount-toggle"
name="hrs-earnings-ammount-toggle"
type="checkbox"/>
<label for="Pluto_35_n40_16_n40_hrs-earnings-ammount-toggle"> Show earnings dollar
amounts</label>
</form>
</th>
</tr>
<tr rsf:id="header:">
<th class="flc-pager-sort-header" rsf:id="paid"><a
href="javascript:;">Paid</a></th>
<th class="flc-pager-sort-header" rsf:id="earned"><a
href="javascript:;">Earned</a></th>
<th class="flc-pager-sort-header" rsf:id="ammount"><a
href="javascript:;">Ammount</a></th>
</tr>
</thead>
<tbody>
<tr rsf:id="row:" class="hrs-clickable">
<td class="hrs-data-text"><a class="todo" href="#" target="_blank"
rsf:id="paid"></a></td>
<td class="hrs-data-text"><a class="todo" href="#" target="_blank"
rsf:id="earned"></a></td>
<td class="hrs-data-number"><a class="todo hrs-earning-ammount" href="#"
target="_blank"
rsf:id="ammount"></a></td>
</tr>
</tbody>
</table>
</div>
</div>
Script:
$("#Pluto_35_n40_16_n40_hrs-earnings-ammount-toggle").change(function() {
if ($(this).is(':checked')) {
$("#Pluto_35_n40_16_n40_hrs-payroll-information table.hrs-table
a.hrs-earning-ammount").show();
}
else {
$("#Pluto_35_n40_16_n40_hrs-payroll-information table.hrs-table
a.hrs-earning-ammount").hide();
}
});
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
