--- Begin Message ---
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
[EMAIL PROTECTED]
Unrouteable address
------ This is a copy of the message, including all the headers. ------
Return-path: <[EMAIL PROTECTED]>
Received: from [83.166.209.187] (helo=[192.168.0.165])
by mail.nuxeo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32)
(Exim 4.63)
(envelope-from <[EMAIL PROTECTED]>)
id 1HKC4s-0008Nx-MG; Thu, 22 Feb 2007 12:25:37 +0100
Message-ID: <[EMAIL PROTECTED]>
Date: Thu, 22 Feb 2007 13:25:34 +0200
From: Narcis Paslaru <[EMAIL PROTECTED]>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Anahide Tchertchian <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: [Ecm-checkins] r12705 - Performace improvement
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.2 (-)
X-Spam-Report: ------------------ Début de Rapport SpamAssassin
---------------------
Ce message est probablement du SPAM (message non sollicité envoyé en
masse, publicité, escroquerie...).
Cette notice a été ajoutée par le système d'analyse "SpamAssassin" sur
votre serveur de courrier "mail.nuxeo.com", pour vous
aider à identifier ce type de messages.
Le système SpamAssassin ajoute un en-tête "X-Spam-Flag: YES" aux
messages qu'il considère comme étant probablement du Spam.
Vous pouvez si vous le souhaitez utiliser cette caractéristique
pour régler un filtre dans votre logiciel de lecture de courrier,
afin de détruire ou de classer à part ce type de message.
Si ce robot a classifié incorrectement un message qui vous était
destiné, ou pour toute question, veuillez contacter l'administrateur
du système par e-mail à the administrator of that system .
Voir http://spamassassin.apache.org/tag/ pour plus de détails (en
anglais).
Détails de l'analyse du message: (-1.2 points, 5.0 requis)
-1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP
0.3 AWL AWL: From: address is in the auto white-list
-------------------- Fin de Rapport SpamAssassin ---------------------
Hello,
Anahide Tchertchian wrote:
> Hi,
>
> 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}" />
>
> I'm aware that this is not optimal. It is due to the way value
> expressions are resolved when rendering a page. I can't see right now
> how it could be dealt with if we would like to keep on using templates
> (in other words macros).
>
>> But instead, it is called everytime documents is referenced in
>> documents_table.xhtml.
>
> Thanks for the info, I did not expect this to happen.
> The table jsf components are surely to be blamed for that, and we've
> been planning on using another component as existing one do not meet
> our performance and feature requirements.
May I suggest displaytag ( http://displaytag.sourceforge.net/11/ ). It's
an open source tag library that deals with table rendering.I've used it
before in other projects with succes. Also we could modify it according
to our specific needs.
What do you think ?
> This is something that will be dealt with soon. In the mean time, I
> think using lazy loading is the way to go.
>
> Now I don't understand how this rendering issues affect the
> publication mechanism: why do you end up publishing the same document
> in the same section 20 times (in one action, I suppose)?
Let me explain :)
For the rendering of the selected children documents there is no problem
because hte selected ones are kept in a separated list :
List<DocumentModel> selectedDocuments = documentsListsManager
.getWorkingList(DocumentsListsManager.CURRENT_DOCUMENT_SELECTION);
What I do for the sections is that when I retrieve them (I compose the
list of sections) I check if that document is published in the section
that I'm retrieving (in a recurrent way) and if so I just add that
section to the list of selected sections(offcourse after seeing this I'm
checking first if that section isn't already in the list).
Si if I was adding all those sections to the list of selected sections,
at the publishing action I just took al the selected sections and
publish the document in them. That's why I wind up with 20 publications
in the same section just for one action. Also, if I uncheck a section
that was checked by default, I think it would still get published.
>
> Cheers,
> anahide.
>
>
>> 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.
>>
>> Any idea is apreciated.
>> Thank you !
>> Narcis Paslaru
>
--- End Message ---
_______________________________________________
ECM mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm
