[dev] [commits] Horde branch ajax_to_core created. f180edabc00d6c0918c423f83864434357bdb881

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>> - Apparently in Kronolith there is an alarm notify option named  
>> 'ajax'.  I don't know what it does, nor really most of the Alarm  
>> notify options, since they are not documented anywhere I know of.   
>> I don't know why this is any different from the url notify option  
>> though - they both create <A> tags.
>
> This is important for the Nag-Kronolith-integration. It allows to  
> link to an object (that raised the alarm) without leaving the  
> current ajax interface. It's really different from the URL option  
> which is a regular deep link.

I don't want to look like I am passing off this work... but any chance  
you could document this somewhere?  Or at least implement the  
necessary functionality at the core level?  Maybe this is a non-issue  
now that we have everything in one place - as long as the core  
handling code is centralized, I can live with having these multiple  
options.

>> In order to make this application-neutral, I've made a change to  
>> Growler that captures any click on an <A> tag within a Growler  
>> notification, stops the event, and fires a 'Growler:linkClick'  
>> event with the <A> element as the passed parameter.  This way, each  
>> application can handle these links as needed.  Obviously, we can  
>> also declare common handling within the base HordeCore code.
>>
>> With this change, there should be no need to declare separate  
>> 'ajax' and 'url' notify options.  You can create the link with the  
>> 'url' option and then do any additional processing in the linkClick  
>> observer.
>
> I don't think this is going to work, because those links tend to  
> come from different applications than the current one. Catching  
> clicks would require knowledge about that application, i.e. how to  
> link to that application's object while you just have a static HTML  
> link.

Good point.  The solution would be to automatically include the  
necessary javascript code within the notification itself, I guess.   
But this code should still never be directly included in the link  
itself - it still should remain separate.

But this is a detail that we can work out going forward.  It's not a  
show-stopper.

>> (Side note: this needs to be the coding paradigm going forward.  At  
>> this point in our development, there should really never be any  
>> need to define on[observer] parameters in HTML tags.  All event  
>> observers should instead be defined in javascript files.  In a MVC  
>> world, this makes sense - we should be separating javascript  
>> entirely from HTML).
>>
>> - Finally, this does not really touch on the smartmobile stuff.   
>> That needs to be centralized ASAP also.
>
> See my other message.

Sounds like we can revisit this in the future, as needed, so there is  
not a show-stopper either.

Testing over the last week, this code is stable - at least that both  
applications work as expected.  At least the most used main features.   
I am going to merge into develop.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]