Re: Fwd: Re: The sidebar resources as viewed from JS

Hi Michael & list,

On 15.12.2015 15:02, Michael J Rubinsky wrote:
> 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
> <[email protected]> -----
>    Date: Tue, 15 Dec 2015 08:59:30 -0500
>    From: Michael J Rubinsky <[email protected]>
> Subject: Re: [dev] The sidebar resources as viewed from JS
>      To: [email protected]
> 
> Quoting Ralf Lang <[email protected]>:
> 
>> 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 missed/overlooked that kronolith dynamic is so close to hermes - I
probably got confused by the "traditional view" code.

>> 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).

I think you gave the answer: kronolith/dyn and hermes/dyn are similar
and the sidebar() method should be left to traditional view apps.

We are currently implementing apps which use HordeCore.doAction() /
Horde_Core_Ajax_Application & friends to load and filter content. These
don't have a traditional view and probably won't ever have. They just
feel "traditional" wherever this was the fastest way to implement.

I was asking the question because

a) lack of documentation on what features not to use in a horde ajax app
- I will add to the wiki what I learn

b) I felt handling of radio resources in dynamic views has not been done
yet and I'd like to contribute the solution, if it is of interest. I
mean strictly: Add and identify radio entries, decide which radio
resources are supposed to be one mutex group, clear already selected
when clicking a new one, delegate actual action to some callback.


> 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.

I will have a look at the ansel_4 branch. I only looked at "master" so far.

> 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.

I'd rather not use imples in anything new.

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

This mail really clarified a lot. :)


-- 
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: [email protected]
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

-- 
dev mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: [email protected]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlZwMIsACgkQCs1dsHJ/X7AoyACgusXYrAA/5sObW5dkFqxpSA4b
XjIAni0o6o4N14IcLL1v0rkTkKT/kZ7u
=XpNj
-----END PGP SIGNATURE-----