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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 >>>>> <[email protected]> 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 >>>>> [email protected] 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 >>>>> [email protected] >>>>> 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 >>>> [email protected] >>>> 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.
_______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
