the faith of midcom_helper_toolbars

Hi, A fairly long discussion that actually ended up in a plan for what
to do with future toolbars :-)


17:11 < bergie_> it is not a bad idea, though can clutter things quite a
bit
17:11 < bergie_> it also looks like going from per-view toolbars to
per-object
17:11 < bergie_> which can have bad effect on performance
17:13 < torben> i'm not sure if performance would be hit that hard, the
acls of each object must be read anyway
17:13 < torben> but the cluttering is a point.
17:13 < torben> we could of course argue that all object-related editing
operations (like those of individual news postings) go to the detail
pages
17:14 < torben> at least for those components which have a detail view
17:14 < bergie_> regarding clutter, you could of course reveal the
control buttons on :hover of that object
17:14 < torben> apart from that, the code is rather simple, so
performance should be good: if (cando) { $edit_url = "{$prefix}/blah"; }
else { $edit_url = null }
17:15 < torben> where prefix =
$_MIDCOM->Get_context_data(MIDCOM_CONTEXT_ANCHORPREFIX);
17:15 < bergie_> it should affect MIDCOM_TOOLBAR_ENABLED, not URL :-)
17:15 < bergie_> so if site template creator wants to show non-allowed
items "greyed out", it should be possible
17:16 < torben> bergie_: once the components affect the toolbars, this
won't be a problem, currently the style still does
17:16 < torben> but please focus on the actual thing, not on my current
workaround...
17:16 < torben> you want to get a final version of this toolbar thing
done, not discussing current workarounds ;-)
17:16 < bergie_> true
17:16 < bergie_> but I like the way the toolbar helper works
17:17 < bergie_> the question here is whether toolbar items are per-view
or per-object
17:18 < torben> this is a big "it depends"
17:18 < torben> example:
17:18 < torben> on taviewer it is always per-view
17:18 < bergie_> BTW, we have some precedents on per-object toolbars...
see the contact list here for example:
http://www.nehmer.net/~bergie/openpsa-newstyle-spammer.jpg
17:18 < bergie_> torben: except on autoindex, right?
17:18 < torben> on newsticker, it is *mostly* per view: the detail pages
are like taviewer, but the index page *could* be per object
17:18 < torben> stuff like simpledb, where there is no detail view,
there it must be per-object
17:19 < bergie_> well, lets work on per-view mainly and allow components
to populate their own toolbars inside their elements if they feel the
need (the newsticker listing example)
17:19 < bergie_> simpleDB does have a detail view
17:20 < torben> so we would have essentially the page-wide top/bottom
(or whatever) toolbars plus any toolbars the app might want to display
17:20 < torben> do we have compact styles for all this yet?
17:34 -!- torbe1 [torben-jie9sTNvGw7Mf3O0FWjaAmxLPjOOzRqzd3tzO6U6LhU@public.gmane.org] has joined
#midgard
17:34 < bergie_> torben: not yet
17:35 -!- torben [torben-jie9sTNvGw4Y6EO3ZrQhIWxLPjOOzRqzd3tzO6U6LhU@public.gmane.org] has quit
[Ping timeout: 181 seconds]
17:35 -!- torbe1 is now known as torben
17:36 < torben> maybe we could build some really compact toolbar by
using some iconic theme supplemented by overlib for the popups (browser
tooltips are just too crappy)
17:37 < tarjei> unlurk. :-)
17:38 < tarjei> hmm, one solution is not to link object toolbars to this
solution in the editing context.
17:39 < tarjei> I'm thinking we should have one floating toolbar at the
top with dropdowns for stuff like styles etc and let the components show
per object toolbars if they want.
17:40 < tarjei> it is not always a good thing to place all issues into
the same solution. We could provide a special toolbar subclass that
implements torbens idea of icons + overlib for perobject toolbars
                (to maintain consistency)
17:41 < torben> tarjei: the toolbars can inherently switch rendering,
that was a base requirement for the toolbar (note the missing s) class.
17:42 < torben> so the site author can basically override this
17:42 < tarjei> torben: by switching rendering do you mean toolbar
style?
17:42 < tarjei> ans in css or html output?
17:42 < torben> yes
17:43 < torben> check the constructor of the toolbar class, it allows
you to pass css info
17:43 < tarjei> ok, what I was thinking was that the per -object toolbar
could be implemented to change the html output and (maybe) change the
html rendering.
17:44 < tarjei> I knew that the toolbar supports different css output.
17:44 < bergie_> can you guys summarize the discussion to dev? I have to
go
17:44 -!- bergie_ [bergie-dWR8d/kOOEo1TROzG3/Z0HJLXXopz9LSJqfE6gh/[email protected]] has quit []
17:46 < torben> tarjei: it should be possible to provide a "symbol"
toolbar by subclassing
17:46 < torben> actually i think this is the only real way, as js stuff
like overlib will need changes to renderin
17:46 < torben> +g
17:48 < tarjei> ok, then we agree
17:48 < tarjei> btw for multipage forms, can I use different handlers
for different forms?
17:50 < torben> theoretcally yes, as you can use the next/previous
events to switch handlers
17:50 < torben> n.n.account does that
17:51 < tarjei> ok, I think that is the way to implement the next gen
sitewizard
17:51 < tarjei> how should we summerize the discussion above?
17:52 < torben> well, basically new is the idea of object toolbars.
17:52 < torben> that should be small (on screen) basically only showing
icons and use something like overlib for more info
17:52 < torben> then we have the top and bottom toolbars, which are both
view-wide.
17:53 < torben> oh and the aegir_admin (or however it was called)
17:53 < torben> which are all-three view-wide. the admin one is not
changeable by the component, top is (basically!) topic-wide stuff, while
bottom is view-related stuff (which sometimes covers
                object-specific stuff)
17:55 -!- hyy-out is now known as hyy
17:55 < torben> the top/bottom toolbars are too framework controlled,
meaning that the framework (could) insert items there.
17:55 < torben> the object toolbars are fully controlled by the
component, i don't see much of an automatism there
17:56 < torben> although, we could think of forcing object-specific
toolbar creation to be linked to an DBA object (that way metadata could
be integrated at a later point)
17:59 < torben> that should about cover it.
17:59 < torben> the only thing remaining is a bit of api defining
18:01 < torben> to have no problems with DL
18:02 < tarjei> ok, suggested implementation:
18:04 < tarjei> 1. m_helper_toolbars stays as it is today. A renaming of
aegir_location and aegir_menu should be done.
18:05 < tarjei> 2. We add a midcom_helper_objecttoolbar () that
implements the object toolbar and may be used by components when they
want to add a toolbar to one object.
18:06 < tarjei> 3. We define how m_h_toolbars should act when used on
site. My suggestion: a floating div at the top of the page.
18:06 < torben> hm
18:06 < torben> for 1/2: i propose introducint $_MIDCOM->toolbars
18:06 < tarjei> 3.b (forgot something)
18:06 < torben> as a service, not a helper. midcom_services_toolbar
18:06 < torben> midcom_services_toolbars that is
18:07 < tarjei> Sounds like a good idea
18:07 < torben> (the get_instance method could refer to that member)
18:07 < torben> the only thing that is tricky here is context
sensitivity
18:07 < tarjei> back to 3.b: I forgot to add that we need to define how
_menu and _top should be merged/not merged.
18:07 < torben> ack
18:08 < tarjei> yes, I'm not sue what is a good idea wrt to contexts.
18:08 < torben> midom_app has enter/exit context calls, they could
change the reference of the toolbars instance accordingly
18:08 -!- Piotras [[email protected]] has quit ["Leaving"]
18:08 < torben> actually, to go a step further:
18:08 < torben> hm no
18:08 < torben> i am just wondering how a style author should handle
toolbars.
18:09 < tarjei> I think the main issue for the styleauthor is to make
sure the floating div isn't broken.
18:09 < torben> let us put the question how the toolbars should be
visualized by default aside at a moment
18:09 < torben> visualization is the least of all problems
18:09 < tarjei> what I was considering is $toolbar->add($toolbar_array,
$context);
18:10 < torben> no
18:10 < torben> that would enforce the components to always check in
which context they are
18:10 < torben> i have an idea
18:10 < torben> basically we use the power of the request classes with
their (implicitly) context-specific data areas:
18:10 < torben> the toolbars_service does *not* provide direct access to
the toolbars (it can't, as a matter of fact)
18:11 < torben> instead it proveds get_instance methods, like you did,
but some which respect contexts
18:11 < torben> the request base classes pick up these references during
initialization, so that component authors don't have to worry about
obtaining references (which is very error prone, as we have seen
                these days yet again)
18:12 < torben> so that in a request class a component author can do:
$this->_top_toolbar->add ...
18:12 < tarjei> sounds like a nice implementation.
18:12 < torben> where _top_toolbar is of midcom_helper_toolbar or
subclass thereoff
18:12 < tarjei> this can be handled transparently like it is today.
18:12 < torben> yes
18:12 < torben> but it has to go further:
18:13 < torben> the same service need to be used by the style authors to
render the toolbars that are currently active (depending on context)
18:13 < torben> that means that the style-inits of dl styles must have
their own toolbar calls
18:13 < torben> which in turn measn we need some decent docs how to
style dl's effectivly
18:13 < tarjei> but I like $_MIDCOM->toolbars , it should be able to
handle the different contexts
18:14 < tarjei> ok I think we got a plan now.
18:14 < tarjei> who's going to implement it?
18:15 < torben> we both ;-)
18:15 < torben> the point with $_MIDCMO->toolbars usage directly is that
midcom_app is not yet really context aware. that's somethign i want to
put in3.0 as you know
18:15 < torben> so the service msut provide its own context awareness
18:16 < torben> but that is not much of a problem.
18:16 < tarjei> yes I was thinking of adding a MIDCOM_CONTEXT_TOOLBARS
or something like that.-
18:16 < torben> the service must also provide a get_object_toolbar call,
which prepares the object toolbars as we spoke
18:16 < torben> the service must also provide a get_object_toolbar call,
which prepares the object toolbars as we spoke
18:16 < torben> tarjei: its easier, we use the custom component context
key 'midcom.toolbars' much likeNAP uses 'midcom.nav.breadcrumb'
18:17 < torben> i want to keep the main context clear of any service
specific stuff if possible (as this will make refactoring in the future
easier)

-- 
Tarjei Huse <tarjei-y/[email protected]>