[Architecture] Combining complex panels in the preferences framework
Justin Obara
obara.justin at gmail.com
Mon Sep 16 14:02:26 UTC 2013
Hi Alexander,
That's good that you were following that conversation. We haven't really had a chance to dive into the implementation yet, but should start today.
Thanks
Justin
On 2013-09-16, at 9:25 AM, Alexander Milchev <amilchev at asteasolutions.com> wrote:
> Hi Justin,
>
> I saw the issue being discussed between you, Cindy and Antranig later that day in #fluid-work, I just wanted to hear your current update on it.
> Thank you for taking it into consideration! I'll stick with the single template for now.
>
> Best,
> Alexander
>
>
> On Mon, Sep 16, 2013 at 3:55 PM, Justin Obara <obara.justin at gmail.com> wrote:
> HI Alexander,
>
> I replied to you the following day in the IRC channel, but perhaps you weren't actually there or didn't see it. At any rate, it's good to get this on the mailing list.
>
> For the time being, you'll want to stick with a single template. Cindy and I will work on making a new panel combining panel or something of that sort which will allow you to assemble many panels into one. You can see more about this on http://issues.fluidproject.org/browse/FLUID-5131 . There are a couple of comments linking to IRC discussions with Antranig about it.
>
> Cindy and I plan to start working on it today. Let us know if you have any questions about it.
>
> Thanks
> Justin
>
> On 2013-09-16, at 4:28 AM, Alexander Milchev <amilchev at asteasolutions.com> wrote:
>
>> Hi Justin,
>>
>> We last discussed this issue in the IRC channel and as far as I remember, never reached a conclusion.
>> I know it's a rather complex one, please let me know what is its current state anytime soon.
>>
>> Thanks,
>> Alexander
>>
>>
>> On Mon, Sep 9, 2013 at 5:18 PM, Justin Obara <obara.justin at gmail.com> wrote:
>> Hi Alex,
>>
>> I think you should be able to use the style I mentioned, but you have to use the expanded form.
>>
>> So something like this should work.
>>
>> resources: {
>> keyEcho: {
>> url: "../../src/shared/adjusters/html/speakTextTemplate-keyEcho.html"
>> }
>> }
>>
>> Also you don't seem to need the setTimeout for the call to finishInit now. The markup does seem to be appended correctly for me. Although it could be in the wrong place. You'll also need to instantiate the component that uses this markup, after it has been appended to the DOM.
>>
>> Hope that helps.
>> Justin
>>
>> On 2013-09-09, at 8:57 AM, Alexander Milchev <amilchev at asteasolutions.com> wrote:
>>
>>> Hi Justin,
>>>
>>> Thank you for the suggestion! Here are some conclusions I came across while trying to configure it.
>>>
>>> My desire was to omit the keyEcho part in the collective template and instead load its html markup using resources and container.append().
>>> By the way here any name other than "template:" would result in an Uncaught TypeError. When trying to load it with fluid.fetchResources the way you suggested, the panel's container is just doubled - apparently that.options.resources.template.resourceText represents the current (big) html container. This could also be seen by checking this hook in the console.
>>> Appending the keyEcho html section this ugly way is successful, but it is never actually shown and rendered. Perhaps it's a timig issue.
>>>
>>> You could checkout this branch in my repo and have a better look at it.
>>> Let me know if there is any progress!
>>>
>>> Thanks,
>>> Alexander
>>>
>>>
>>> On Tue, Sep 3, 2013 at 4:20 PM, Justin Obara <obara.justin at gmail.com> wrote:
>>> Hi Alexander,
>>>
>>> You may have come upon another limitation, but perhaps there is a way around. The templates block in the options can take in multiple resources e.g.
>>>
>>> resources: {
>>> keyEchoTemplate: {},
>>> wordEchoTemplate: {}
>>> }
>>>
>>> Although I'm not sure how this is handled by the renderer. So you'll have to try it out and see how things go.
>>>
>>> It seems that my example worked because the templates were already combined. If the above suggestion doesn't work, you could manually insert the fetched templates into the DOM, which should allow the renderer to see it. In the above example you would find the template markup at "that.options.resources.keyEchoTemplate.resourceText" and "that.options.resources.wordEchoTemplate.resourcetext". You can insert it into the DOM with something like jQuery's append.
>>>
>>> You can see something similar from UIO.
>>> https://github.com/fluid-project/infusion/blob/master/src/components/uiOptions/js/UIOptions.js#L416
>>>
>>> However, that being said you might run into issues with the auxiliary schema, as it's probably not setup to accept multiple templates for a single component.
>>>
>>> Let me know if you have any more thoughts and/or expectations for how you'd like this to all work.
>>>
>>> Thanks
>>> Justin
>>>
>>> On 2013-09-02, at 8:45 AM, Alexander Milchev <amilchev at asteasolutions.com> wrote:
>>>
>>>> Hi Anastasia,
>>>>
>>>> Thank you for the reply, but I'm afraid you got me wrong. Perhaps I should explain myself better.
>>>>
>>>> My ambition is to break a bigger panel so that each piece has its own template.
>>>> The question is relevant to the grade merging, discussed previously in this thread. I've been working on the Speak Text adjuster group and I tried to merge these two panels into this big one, as Justin suggested. The important part of the auxSchema is that both adjusters' panels' type is the big panel (keyEcho, wordEcho) and all this information is overwritten by the last defined, so these selectors are looked for in this template, instead of the appropriate one.
>>>>
>>>> Is there an elegant way to work around this?
>>>>
>>>> Thanks,
>>>> Alexander
>>>>
>>>>
>>>> On Mon, Sep 2, 2013 at 3:32 PM, Chris Petsos <cpetsos at certh.gr> wrote:
>>>> Hi Alexander,
>>>>
>>>> I don't know if this is what you need, but in my version of PMT the "big panel" is here and all the "sub-panels" are here (e.g. magnifier-follows, magnifier-position etc.) separate from each other. This is something that is supported out-of-the-box in UIO. You'll get a feeling of how it's being done if you browse the code a bit. Feel free to ask if you have any questions. I don't know if some specialized grade merging is needed for that; or are you trying to perform something more sophisticated?
>>>>
>>>> Cheers,
>>>>
>>>> Chris.
>>>>
>>>>
>>>> On 09/02/2013 03:26 PM, Alexander Milchev wrote:
>>>>> Hi Anastasia,
>>>>>
>>>>> Thank you for the reply, but I'm afraid you got me wrong. Perhaps I should have explained myself better.
>>>>>
>>>>> My ambition is to break a bigger panel so that each piece has its own template.
>>>>> The question is relevant to the grade merging, discussed previously in this thread. I've been working on the Speak Text adjuster group and I tried to merge these two panels into this big one, as Justin suggested. The important part of the auxSchema is that both adjusters' panels' type is the big panel (keyEcho, wordEcho) and all this information is overwritten by the last defined, so these selectors are looked for in this template, instead of the appropriate one.
>>>>>
>>>>> Is there an elegant way to work around this?
>>>>>
>>>>> Thanks,
>>>>> Alexander
>>>>>
>>>>>
>>>>> On Fri, Aug 30, 2013 at 10:27 PM, Cheetham, Anastasia <acheetham at ocadu.ca> wrote:
>>>>>
>>>>> On 2013-08-30, at 9:43 AM, Alexander Milchev wrote:
>>>>>
>>>>> > Hi everyone,
>>>>> >
>>>>> > I tried out the grade merging today and a question popped up.
>>>>> >
>>>>> > It seemed to me that no more than one html template could be shared between multiple users of the same panel. This would be the template of the adjuster, defined last in the auxSchema. For instance (in Justin's example), if the auxSchema relates the big panel "fluid.uiOptions.panels.linksControls" to both emphasizeLinks and imputsLarger adjusters and imputsLarger is defined second, then info for template, container and message for emphasizeLinks is neglected and overwritten by those of imputsLarger.
>>>>> >
>>>>> > Does this mean that all templates must be stuffed in one big html file (hope it doesn't) and how can the templates be apportioned properly?
>>>>> >
>>>>> > Thanks,
>>>>> > Alexander
>>>>>
>>>>> Hi, Alexander,
>>>>>
>>>>> It's possible I'm not quite understanding your question, and if so, please forgive me. But it is certainly possible for each panel to have its own template.
>>>>>
>>>>> The auxiliary schema for the starter panels shows how this is done:
>>>>> https://github.com/fluid-project/infusion/blob/master/src/components/uiOptions/js/StarterSchemas.js
>>>>>
>>>>> The root part of the schema defines the template that will contain all of the panels:
>>>>> https://github.com/fluid-project/infusion/blob/master/src/components/uiOptions/js/StarterSchemas.js#L34
>>>>> This template contains an empty div for each panel.
>>>>>
>>>>> The root part of the schema also defines a root directory for the individual panels:
>>>>> https://github.com/fluid-project/infusion/blob/master/src/components/uiOptions/js/StarterSchemas.js#L33
>>>>>
>>>>> Each of the panel blocks specifies its own template relative to the root directory:
>>>>> https://github.com/fluid-project/infusion/blob/master/src/components/uiOptions/js/StarterSchemas.js#L45
>>>>> https://github.com/fluid-project/infusion/blob/master/src/components/uiOptions/js/StarterSchemas.js#L66
>>>>> https://github.com/fluid-project/infusion/blob/master/src/components/uiOptions/js/StarterSchemas.js#L87
>>>>> etc.
>>>>>
>>>>> (It isn't necessary to use the root directory prefix, that's just something you can use if it's helpful.)
>>>>>
>>>>> Alexander, does this answer your question, or am I confused?
>>>>>
>>>>> --
>>>>> Anastasia Cheetham Inclusive Design Research Centre
>>>>> acheetham at ocadu.ca Inclusive Design Institute
>>>>> OCAD University
>>>>>
>>>>>
>>>>>
>>>>> The information in this e-mail and any accompanying files is intended only for the recipients named above. This message may contain CONFIDENTIAL INFORMATION THAT IS LEGALLY PRIVILEGED. If you are not an intended recipient, you may not download, copy, disseminate, distribute or use in any way the information in this e-mail. Any of these actions can be a criminal offense. If you have received this e-mail in error, please notify Astea Solutions AD immediately by reply e-mail, and delete this e-mail and any copies of it.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> Architecture at lists.gpii.net
>>>>> http://lists.gpii.net/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>>
>>>> The information in this e-mail and any accompanying files is intended only for the recipients named above. This message may contain CONFIDENTIAL INFORMATION THAT IS LEGALLY PRIVILEGED. If you are not an intended recipient, you may not download, copy, disseminate, distribute or use in any way the information in this e-mail. Any of these actions can be a criminal offense. If you have received this e-mail in error, please notify Astea Solutions AD immediately by reply e-mail, and delete this e-mail and any copies of it.
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> Architecture at lists.gpii.net
>>>> http://lists.gpii.net/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>>
>>> The information in this e-mail and any accompanying files is intended only for the recipients named above. This message may contain CONFIDENTIAL INFORMATION THAT IS LEGALLY PRIVILEGED. If you are not an intended recipient, you may not download, copy, disseminate, distribute or use in any way the information in this e-mail. Any of these actions can be a criminal offense. If you have received this e-mail in error, please notify Astea Solutions AD immediately by reply e-mail, and delete this e-mail and any copies of it.
>>
>>
>>
>>
>> --
>> Alexander Milchev
>> Entry Level Software Engineer
>> Astea Solutions AD
>>
>> The information in this e-mail and any accompanying files is intended only for the recipients named above. This message may contain CONFIDENTIAL INFORMATION THAT IS LEGALLY PRIVILEGED. If you are not an intended recipient, you may not download, copy, disseminate, distribute or use in any way the information in this e-mail. Any of these actions can be a criminal offense. If you have received this e-mail in error, please notify Astea Solutions AD immediately by reply e-mail, and delete this e-mail and any copies of it.
>
>
>
>
> --
> Alexander Milchev
> Entry Level Software Engineer
> Astea Solutions AD
>
> The information in this e-mail and any accompanying files is intended only for the recipients named above. This message may contain CONFIDENTIAL INFORMATION THAT IS LEGALLY PRIVILEGED. If you are not an intended recipient, you may not download, copy, disseminate, distribute or use in any way the information in this e-mail. Any of these actions can be a criminal offense. If you have received this e-mail in error, please notify Astea Solutions AD immediately by reply e-mail, and delete this e-mail and any copies of it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20130916/49386df8/attachment.htm>
More information about the fluid-work
mailing list