Hello, I created a ticket and attached a patch for removing the MARK_DELETED attribute from the component. The JIRA ticket is: https://issues.apache.org/jira/browse/MYFACES-2774. Please have a look over it and tell me whether I should modify anything.
Regards, Marius On Fri, Jun 25, 2010 at 2:12 PM, Marius Petoi <[email protected]>wrote: > Hello, > > Thank you for the explanations! So, as I see here, it is ok to remove the > "org.apache.myfaces.view.facelets.MARK_DELETED" attribute from the partial > state and include it in the FaceletContext (as a list of components that are > marked for deletion). > > Regards, > Marius > > > On Fri, Jun 25, 2010 at 2:20 AM, Leonardo Uribe <[email protected]> wrote: > >> Hi Martin >> >> 2010/6/24 Martin Marinschek <[email protected]> >> >> Hi Leonardo, >>> >>> > The param "org.apache.myfaces.view.facelets.APPLIED" is used with the >>> web >>> > config param javax.faces.FACELETS_REFRESH_PERIOD, to detect changes on >>> the >>> > template files. If you set this param to 0, facelets stops to add it >>> and >>> > your state size is reduced, so that configuration must be used in >>> production >>> > environments. >>> >>> so that is in all components? and it is only for reloading? wouldn't >>> it be enough to have this once per view? In the view-root attributes >>> map? then, if any of the files which are loaded are younger than this >>> param, we drop the whole thing and reload? I thought the MARK_APPLIED >>> was for something else, but I don't remember too well... I am >>> concerned even about polluting the state while development - it makes >>> the debugging harder. >>> >> >> MM> so that is in all components? >> >> It is applied by DefaultFacelet to the component instance that contains a >> reference to a template. >> There are three cases: >> >> - When the first facelet is applied (call to Facelet.apply(FacesContext >> facesContext, UIComponent parent) ) >> - When a composite component template is applied (call to >> DefaultFacelet.applyCompositeComponent(AbstractFaceletContext ctx, >> UIComponent parent, Resource resource) ) >> - When a template is included (call to >> DefaultFacelet.include(AbstractFaceletContext ctx, UIComponent parent, URL >> url) ) >> >> So it appears based on how the page use templates or composite components. >> >> MM> and it is only for reloading? >> >> Yes. >> >> MM> wouldn't it be enough to have this once per view? In the view-root >> attributes map? >> >> If we let it just once per view and it is changed a child template, the >> current view will not be updated because it contains the update time of the >> base template. It seems possible to use this attribute just once, but to do >> that it is necessary to change the whole algorithm. >> >> MM> if any of the files which are loaded are younger than this param, we >> drop the whole thing and reload? >> >> Looking in deep the current algorithm is not using file modification times >> as I was expecting (so it does not look for changes), instead it is using as >> base time the creation time of the Facelet object. So, the algorithm just >> refresh the templates at specified intervals. >> >> It seems we can do something more simple here and do not pollute the >> state. >> >> >>> > I think it is possible to do something about >>> ComponentSupport.MARK_DELETED. >>> > The algorithm used to refresh a view by facelets uses this param to >>> indicate >>> > when a component should be deleted, but I think we can rewrite the >>> algorithm >>> > to do not use the component attribute map to save this information, >>> because >>> > it is only relevant for the current request. >>> >>> For even less, right? It should really be valid only for one building >>> of the view - can we keep it in some facelet-context attribute, keyed >>> by the component instance (so that the lookup is fast)? >>> >>> >> Yes, that's the idea. >> >> best regards, >> >> Leonardo >> >> >>> > Maybe we should change the keys for example from >>> > "org.apache.myfaces.view.facelets.MARK_DELETED" to something smaller >>> like >>> > "oam.facelets.MARK_DELETED" to save some bytes. >>> >>> ah well, it should go completely. Everything else is only half the rent. >>> >>> best regards, >>> >>> Martin >>> >>> > 2010/6/24 Marius Petoi <[email protected]> >>> > >>> >> Hello, >>> >> >>> >> As you said, Martin, the attribute >>> >> "org.apache.myfaces.view.facelets.APPLIED" is included in the partial >>> >> state. >>> >> This, as well as all the other attributes of the components, as the >>> >> attributeMap in the UIComponentBase is a _ComponentAttributesMap. The >>> put >>> >> method of this map calls afterwards the method in the >>> _DeltaStateHelper. >>> >> This method includes everything in the partial state (as long as the >>> >> initial >>> >> state is marked). This means that all the attributes of a component >>> will >>> >> be >>> >> included in the partial state. I suppose that there are other >>> attributes >>> >> as >>> >> facelets.APPLIED, which don't need to be included in the partial >>> state. >>> >> >>> >> So my suggestion at first would be to add flags to the "put" methods >>> of >>> >> the >>> >> _DeltaStateHelper, in which to decide whether the value added needs to >>> be >>> >> in >>> >> the partial state (and therefore added in the _deltas map), or not (in >>> >> which >>> >> case it will be added only in the _fullstate map). Afterwards, we >>> should >>> >> revise all the attributes and decide whether they need to be in the >>> >> partial >>> >> state or not and call the put methods with the apropriate flag. >>> >> >>> >> What do you think? >>> >> >>> >> Regards, >>> >> Marius >>> >> >>> >> >>> >> On Wed, Jun 23, 2010 at 4:54 PM, Martin Marinschek < >>> [email protected] >>> >> > wrote: >>> >> >>> >>> Hi Marius, >>> >>> >>> >>> I think you will easily find out candidates for a better >>> >>> implementation - just take a look at the partial state of any of the >>> >>> components. Something that comes immediately to my mind is >>> >>> facelets.MARK_APPLIED - this is only relevant in request-scope, but >>> is >>> >>> currently in the partial state, both in Mojarra and MyFaces (last >>> time >>> >>> I looked). >>> >>> >>> >>> Stuff like this needs to be fixed. Tell us if you have more >>> information. >>> >>> >>> >>> best regards, >>> >>> >>> >>> Martin >>> >>> >>> >>> On 6/18/10, Leonardo Uribe <[email protected]> wrote: >>> >>> > Hi >>> >>> > >>> >>> > I think the key classes are UIComponentBase , _DeltaStateHelper and >>> >>> > _DeltaList. Take a look at UIComponentBase.saveState() and >>> >>> > UIComponentBase.restoreState(). Those methods have calls to other >>> >>> methods >>> >>> > that are critical to state saving. I remember UIViewRoot has other >>> >>> methods >>> >>> > too. I think check those classes are a good point to start. >>> >>> > >>> >>> > regards, >>> >>> > >>> >>> > Leonardo Uribe >>> >>> > >>> >>> > 2010/6/18 Marius Petoi <[email protected]> >>> >>> > >>> >>> >> Hello, >>> >>> >> >>> >>> >> In order to study the current performance of state saving, I >>> designed >>> >>> >> a >>> >>> >> small page that I included in the examples for MyFaces 2.0. Also, >>> I >>> >>> wrote >>> >>> >> 2 >>> >>> >> phase listeners that determine the length of the state saved in >>> the >>> >>> >> ExternalContext before the render response phase and before the >>> >>> >> restore >>> >>> >> view >>> >>> >> phase. Do you have any suggestions what components should I start >>> >>> >> analyzing >>> >>> >> the state for? >>> >>> >> >>> >>> >> Regards, >>> >>> >> Marius >>> >>> >> >>> >>> > >>> >>> >>> >>> >>> >>> -- >>> >>> >>> >>> http://www.irian.at >>> >>> >>> >>> Your JSF powerhouse - >>> >>> JSF Consulting, Development and >>> >>> Courses in English and German >>> >>> >>> >>> Professional Support for Apache MyFaces >>> >>> >>> >> >>> >> >>> > >>> >>> >>> -- >>> >>> http://www.irian.at >>> >>> Your JSF powerhouse - >>> JSF Consulting, Development and >>> Courses in English and German >>> >>> Professional Support for Apache MyFaces >>> >> >> >
