Mailing List Archive: Bricolage: devel

Fwd: Re: Bric2 callbacks: trail_cb and update_cb

Index | Next | Previous | View Threaded

mercie_s at denison

Feb 5, 2009, 6:48 AM

Post #1 of 3 (1095 views)
Permalink

Fwd: Re: Bric2 callbacks: trail_cb and update_cb

We are currently working on fixing problems discovered with the add
and deletion of elements in bric2. After updating to the latest
versions of prototype and scriptaculous, we've come to the conclusion
that the errors have something to do with the callbacks the form tries
to execute.

So, we were just wondering if someone could tell us what
"story_prof|update_cb" and "story_prof|trail_cb" are trying to do, and
where they are physically housed within the bricolage framework, to
help us along the way to making them compatible with the current
libraries.

The errors we're seeing:

If we try to add or delete an element, we see:

"Can't call method "get_version" on an undefined value at
/usr/local/bricolage/lib/Bric/App/Callback/Profile/Story.pm line 292"

If we remove the update_cb from the top of
comp/widgets/story_prof/edit_meta.html and we try to add an element,
if it is the first element added on the page it will add it correctly.
If you then try to add another element, it will replace the element
above it you previously added. If you then go away from the story and
return, all elements you added magically reappear in the correct order
in which you added them. When trying to delete an element, no error
is produced, but the element is not actually deleted either.

If we then also remove trail_cb, we can delete elements just fine
sometimes. Other times it will say it deleted an element but the
element will not disappear. When adding elements, behavior is the
same as before when we only removed update_cb.

Thanks,
Sarah Mercier

lannings at who

Feb 5, 2009, 7:09 AM

Post #2 of 3 (1023 views)
Permalink

Re: Fwd: Re: Bric2 callbacks: trail_cb and update_cb [In reply to]

On Thu, 5 Feb 2009, mercie_s [at] denison wrote:
> So, we were just wondering if someone could tell us what
> "story_prof|update_cb" and "story_prof|trail_cb" are trying to do, and where
> they are physically housed within the bricolage framework,

The callbacks are under lib/Bric/App/Callback/ .
The error message points to the one for story_prof.
Left of the pipe is the CLASS_KEY in the class.
(story_prof is a little different because it's in Story.pm
under Callback/Profile/ while most are just under Callback
and have the same name as the CLASS_KEY.)
To the right, strip off "_cb" and the rest is the name
of a method, in this case `update' and `trail'.
So search for "sub update" and "sub trail" in Callback/Profile/Story.pm .

You might look in Params::CallbackRequest and/or Params::Callback
(by David) for more detailed docs.

mercie_s at denison

Feb 12, 2009, 6:42 AM

Post #3 of 3 (990 views)
Permalink

Re: Fwd: Re: Bric2 callbacks: trail_cb and update_cb [In reply to]

> You might look in Params::CallbackRequest and/or Params::Callback
> (by David) for more detailed docs.

Looked at the callbacks and after some testing and comparisons with
trunk, we found that the problem might deal more directly with the
changes between the old prototype and the new one. In
/comp/media/js/lib.js, when we are trying to get the parameters to
pass to the Ajax Updater, we use a prototype function called
'serialize.'

When looking at the changes in this function between Prototype 1.5.0
rc0 and the new version (1.6.0.3), we found that the way elements in
the form are collected is vastly different. Whereas in the older
version, serialize grabs only certain elements, the newer version
grabs all elements in the form.

If we print out the parameters being passed to the Updater, we can
easily see this, as we get things like the 'Save and Stay' buttons and
the 'Cancel' buttons whereas on trunk, we do not.

Another interesting problem we have when running the new prototype is
we get what appears to be a mutated version of what should be the
parameter
"container_prof|element_<container_id?>=dat<element_id?>." The new
prototype grabs this and passes it, but it also passes a malformed
version of this parameter immediately before, which looks something
like "container_prof|<element_id?>=(NULL)."

If extra parameters are being passed to the Updater, would this cause
the error? Does the malformed parameter have any effect on the
Updater? Any ideas as to how we should approach this problem?

Thanks,
Sarah Mercier

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads