On Jueves, 10 de Diciembre de 2009 12:36:13 Ed W escribió:
> Hi
>
> Sorry, got distracted for a few days...
>
> >> (in list_column_helpers)
> >> def render_list_column
> >> self.send("column_#{column}")
> >> rescue
> >> define_render_list_column #create a column override function
> >> self.send("column_#{column}")
> >> end
> >> end
> >
> > I don't know if it's a good idea. It could break per-request
> > configuration, changing form_ui in create and update actions for example,
>
> Hmm, actually I don't think so? In any case the rough proposal is
> effectively that we cache the calculation of figuring out how to render
> each column - as you say later, there are quite a few ways to achieve
> this, this is just one way!
>
> However, to continue this idea a bit further:
>
> - Currently with the ruby VM, calling a function which does not exist
> and then "rescue"ing is moderately expensive when the call fails.
> However, it's very cheap for every subsequent call when we don't get a
> rescue. In comparison checking for the existence of a function before
> calling it is less expensive than a rescue, but adds up quite a bit if
> we call it every time.
>
> - So the idea was that currently you can override a column format
> function by declaring some function "mycol_column", so what we do is
> define these for every column it doesn't already exist. Additionally
> the icing would be to define it somewhere above the controller class so
> that if the user dynamically creates this function in some per-row
> config it will override our function. However, if this is not possible
> I think it's only a minor tweak to adjust the per_row/per_request
> functions to override the newly created functions - one simple solution
> would be to define the renderme_column function to literally figure out
> the column type for each call (ie revert back to old per call dynamic
> rendering)
I'm not talking about define dynamically a helper (form/field override), I was
talking about changing form_ui per-request for example. It would break that
uses, and it would need to change form_ui and call a method to redefine that
helper. I was thinking in undefine the method, but it's not needed, you only
need to redefine the method.
>
>
> The big picture here though is that we separate out a library of tight
> column rendering helpers (which can still be overridden as per now), but
> separate these quite clearly from the function which figures out how we
> want to render the column
>
> The current situation is that we run a ton of code to figure out how to
> render a column, and then right down in the bowls of that function we
> call the render function. This makes for example figuring out how to
> add a date format helper quite involved in terms of figuring out how to
> hook into this. Instead our algorithm should be to be one pass to
> figure out how to render the column, then another pass to run that
> render function (much easier to debug and extend)
I agree with this, but I think it's not needed dynamically define methods, I
think it's enough to cache the result of first pass, and I think it would
consume less memory.
> The interesting bit about this idea is that with some tweaking it could
> be made to run at boot time and not per-request. Would need a bit of
> thought on how to handle per-request overrides of column rendering
> (personally I think it's acceptable to make the user define per-column
> renderers to override ours - these can make use of all the built-in AS
> code so they can be quite efficient functions and perhaps defined
> dynamically)
It should not be hard add another method to run after active_scaffold block, as
method which sets links for association columns. If a filter change form_ui
per-request only has to use this method to calculate again which method use to
render the column.
--
Sergio Cambra .:: entreCables S.L. ::.
Mariana Pineda 23, 50.018 Zaragoza
T) 902 021 404 F) 976 52 98 07 E) [email protected]
--
You received this message because you are subscribed to the Google Groups
"ActiveScaffold : Ruby on Rails plugin" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/activescaffold?hl=en.
