[dev] Fwd: Re: The sidebar resources as viewed from JS

Tue Dec 15 14:02:24 UTC 2015

Hm. For some reason IMP has decided to start ignoring my identity  
prefs and send everything using my non-horde email. Forwarding to the  
list.

----- Forwarded message from Michael J Rubinsky  
<mike at theupstairsroom.com> -----
    Date: Tue, 15 Dec 2015 08:59:30 -0500
    From: Michael J Rubinsky <mike at theupstairsroom.com>
Subject: Re: [dev] The sidebar resources as viewed from JS
      To: dev at lists.horde.org

Quoting Ralf Lang <lang at b1-systems.de>:

> Hi,
>
> I am currently examining the sidebar resources handling.
>
> In a plain horde application (from skeleton), one would add sidebar
> resources via $app_Application->sidebar derived from Horde_Core_Application.
>
> This would generate pretty bare "radio" or "checkbox" resources - they
> have no identifying id, class or other element and the radios would not
> have any relation besides living on the same container. For a
> traditional static render-and-forget app, this works well but for
> dynamic, it seems not ideal.
>
> In kronolith/dynamic, resources are added via js and generate a slightly
> different html code for the resources (checkboxes only).
> They store the actual context  of the checkbox via prototypeJS' store()
> method.

Kronolith/dynamic also uses the Kronolith_View_Sidebar:: method (like  
Hermes, below), as this is the dynamic view way of rendering it. The  
actual calendar resources are appended via JS since they are obtained  
from various AJAX calls after the UI has loaded.

> In Hermes/dynamic,
>
> the sidebar() method is ignored and a separate Hermes_View_Sidebar /
> sidebar.html.php is rendered which actually has IDs to refer to.

Hermes_Application::sidebar is used, but only for the traditional view  
(as in the other dynamic apps as well). The only items added from  
Hermes_View_Sidebar are static links/informational displays. The  
remaining data (Timers) are loaded via AJAX like calendars in  
kronolith. Also, FWIW, we store context for the Timers via the  
.store() method here as well.

> -------
>
> I am currently trying to use a group of "radio" entries to switch some
> application content without actually reloading the site.
>
> First thing obviously is to identify the clicked entry, find all radios
> which logically belong together to this group, disable the currently
> active radio and enable the clicked radio - and then do whatever it is
> supposed to achieve.
>
> Which solution would be acceptable for re-use in other horde apps (i.e.
> turba)?

FWIW, turba has always been it's own little bag-of-monkeys - mostly  
because of the way individual address books are never shown together  
(unlike other apps where we can view multiple resources on the same  
view), and the complexities of allowing both share and non-share based  
address books - but I digress...

> 1) Amend the sidebar() generated code with optional class for logically
> grouping radio items and optional id to make use of them in javascript code
>
> 2) Generate dynamic-view resources in javascript code, including
> class/id needed for handling
>
> 3) The hermes way

I admit I'm not 100% sure exactly what the differences are between 2  
and 3 since they seem to me to be very similar and I'm not clear if  
you are doing this in a traditional or dynamic app (your points above  
seem to refer to both).

The current way of doing this in a *dynamic* view is to create static  
links in the PHP template (via {Application}_Template_Sidebar) and  
create resource links (like calendars) via javascript when they are  
loaded via Ajax. Then, utilize the clickHandler in javascript and  
switch on either DOM id, or other CSS selector such as class name.   
IMO, this gives the greatest flexibility: We can assign DOM id when  
really needed (they are more expensive for the browser), create  
whatever custom logic we need to handle the  
enabling/disabling/hiding/etc... of other related links based on  
whatever state we want.

E.g., I'm currently working on adding a dynamic view of Ansel and have  
"view filters" in the sidebar that indicate if the content displayed  
are for all users, just the current user, or just to "subscribed"  
galleries. I catch the clicks on these based on DOM id and in my  
various loadView type of methods, I set the state of other UI elements  
accordingly. Since there are other menu items whose state affects the  
content displayed (are we viewing galleries, images, a map, date  
browsing etc...) it wouldn't really be feasible with a  
one-size-fits-all sidebar handling code.

If you are talking about changing some content in an ajax-y way in a  
traditional view app, you are probably going to need to use our Imple  
pattern to attach the functionality to the UI element and handle the  
resulting action.

Does this even get close to answering your question? ;)

> Is there any plan to refactor that in H6 or horde 5.next?

Not that I know of, but that doesn't mean it can't be.

-- 
Mike

----- End forwarded message -----

-- 
mike
The Horde Project
http://www.horde.org
https://www.facebook.com/hordeproject
https://www.twitter.com/hordeproject
-------------- next part --------------
An embedded message was scrubbed...
From: Michael J Rubinsky <mike at theupstairsroom.com>
Subject: Re: [dev] The sidebar resources as viewed from JS
Date: Tue, 15 Dec 2015 08:59:30 -0500
Size: 5153
URL: <http://lists.horde.org/archives/dev/attachments/20151215/949e4219/attachment.mht>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5751 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/dev/attachments/20151215/949e4219/attachment.bin>