search

netzke / netzke-core

Framework for Sencha Ext JS + Ruby on Rails client-server components
http://netzke.org
Other
263 stars 77 forks source link

Calling for a endpoint causes the entire config tree branch to be parsed. #23

Closed vimutter closed 12 years ago

vimutter commented 13 years ago

There should be ability to make some components cachable, so endpoints calls on them should not parse entire application config.

For example consider such components: main -> sub -> c. So when calling endpoin defined on c, we get both main, sub and c configs parsed. It will be good to have opportunity to make c accessible directly.

mxgrn commented 13 years ago

It's a very interesting idea, but it probably won't work in case when the config contains objects that can't be safely serialized to be stored in the session. An example: say, the component "c" from your example receives as a parameter the instance of its container, the component "sub". Maybe we could implement the caching in such a way, that the developer will decide which components support caching, and which don't. Does it make sense? Would love to hear your opinion.

vimutter commented 13 years ago

Yes, there should be some option, for example :cache, that indicates how the endpoints will be stored. Also, for the storing in session we could use some cleaning os the Hash itself, to clean-up proc and non-serializable objects. And of course the ensurement that component is cachable should be on developers side. So how do you think? I have experimented with cashing in session, and it appeared to work.

mxgrn commented 13 years ago

I'm not sure why you refer to endpoints where I was thinking about caching the complete config for (deeply nested) components. I suppose, this work would need to be done in invoke_endpoint in services.rb. So, it will probably be a component's config option which will command Core to store this component's configuration in session cache. I'll be watching closely your experiments if that was the intention of forking Core. Thanks so far!

vimutter commented 13 years ago

You are right, the main idea was about caching config. I will try to experiment on it closely as I can.

mxgrn commented 12 years ago

Eventually, I came to the conclusion that with the right component design, instantiating the component tree should not be a problem. What we should simply avoid is to put too much into "def configure" (v0.8.x), leaving as much as possible to "def js_configure", which is not called at instantiating the component (e.g. with the aim of processing an endpoint call).