Hello Olivier,
Olivier Grisel wrote:
Narcis Paslaru a écrit :
Hello everybody,
I think this method should be called only ones when it is referenced
from document_content.xhtml
<ui:decorate template="/incl/documents_table.xhtml">
<ui:param name="documents"
value="#{documentActions.childrenSelectModel}" />
But instead, it is called everytime documents is referenced in
documents_table.xhtml.
Yes ui:param just set an alias to a value binding in this case.
This is not good because I've used this as an example and the diffrence
was that here no document needed to be selected by default, so the
getter kept getting all the documents (this is quite an overhead if
there are many documents, but the functionality was ok). Now some
documents(sections in my case) need to be checked by default. For this
to happen in the getter method getChildrenSelectModel
(getsectionsSelectModel in my case) I added some sections to the list of
selected sections. Imagine adding the same sections to the list 20 times
=> when I publish, I end up publishing the same document 20 times in the
same section.
Now I almost found a workaround(some kind of lasy loading - but it's not
100% safe) and the method still gets called so many times. I think this
problem is quite important because it happens in document_content page -
that is used so often.
As I told you before, a possible solution would be to compute the "documents"
value only once with nxu:methodResult instead but this will only work with
serializable objects which is not the case of SelectModels at the moment
(because it is reusing the tomahawk implementation which is not serializable
AFAIK). This strategy is used in the dashboard document listing with
DocumentModelList that are serializable.
The other solution would be to make DocumentActions.getChildrenSelectModel store
a cached version of the results and invalidate it upon
DOCUMENT_SELECTION_CHANGED events as this is done in other beans. I remember
doing a that sort of thing in SecurityActionsBean for instance.
You are right about this, this might fix the publishing issue, but there
is still a performance issue. For example when I was trying to clean a
section of mispublished documents (there were about 100) when I was
clicking 1 document the CPU stood at 100% for about a second (and I have
a 2GHz Intel Pentium M). What if 10 users like me where doing this
simultaneously ?
Cheers,
Narcis Paslaru
_______________________________________________
ECM mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm
