On Thu, Nov 11, 2010 at 7:16 AM, Luciano Resende <[email protected]> wrote: > On Wed, Nov 10, 2010 at 12:49 AM, Simon Nash <[email protected]> wrote: >> ant elder wrote: >>> >>> On Sun, Oct 24, 2010 at 5:06 PM, Luciano Resende <[email protected]> >>> wrote: >>>> >>>> On Sun, Oct 24, 2010 at 8:40 AM, ant elder <[email protected]> wrote: >>>>> >>>>> On Sun, Oct 24, 2010 at 4:30 PM, Luciano Resende <[email protected]> >>>>> wrote: >>>>>> >>>>>> On Sun, Oct 24, 2010 at 4:17 AM, Simon Nash <[email protected]> wrote: >>>>>>> >>>>>>> ant elder wrote: >>>>>>>> >>>>>>>> I'm trying to understand what it is the real purpose of all the >>>>>>>> Tuscany dojo modules: >>>>>>>> >>>>>>>> tuscany-binding-atom-js-dojo >>>>>>>> tuscany-binding-jsonrpc-js-dojo >>>>>>>> tuscany-implementation-widget-runtime-dojo >>>>>>>> tuscany-web-javascript-dojo >>>>>>>> >>>>>>>> Can anyone help with some details? >>>>>>>> >>>>>>>> ...ant >>>>>>>> >>>>>>>> >>>>>>> These are used by the store-dojo sample. If you look at the >>>>>>> store.html file >>>>>>> within that sample you will find some Javascript references to dojo >>>>>>> things. >>>>>>> There are also a few differences in the Javascript code when compared >>>>>>> with >>>>>>> the same code in the store sample. This might provide some clues :-) >>>>>>> >>>>>>> Simon >>>>>>> >>>>>>> >>>>>> These modules provide support for "Javascript Proxies" for >>>>>> Implementation widget. They are based on Dojo Javascript Framework. >>>>>> >>>>> So they're only used with implementation.widget? >>>>> >>>>> ...ant >>>>> >>>> Yes, and some of they are optional depending on the binding you are >>>> using in conjunction with implementation.widget. >>>> >>> >>> Now that this thread has come up again it reminds me i'd asked about >>> them. if they're for implementation.widget could we have widget in the >>> module name to make that more clear? And now that we have the base + >>> extension approach and these don't drag in extra dependencies wouldn't >>> it be possible to just have them part of the widget runtime module so >>> there are no extra modules at all? >>> >>> ...ant >>> >>> >> I'll toss in another suggestion. Instead of parallel sets of these >> 4 modules (one that uses dojo and one that doesn't), could the dojo and >> non-dojo flavours of each module be combined, with runtime code in the >> module to select which flavour should be used? >> >> Simon >> >> > > The issue here is with regards to embedders, which will use some of > these mmodules but not all. If we combine them, this is not going to > be possible anymore. If we make the choice via runtime, particularly > in 2.x, this will have implications on the embedders, so I'd ask them > first. > > I'll take a look in 2.x and figure out if there is a better layout for > these modules, as they shouldn't have big implications on embedders > (AFAIK) >
I don't understand why this has impact on embedders, can you explain you concerns in more detail? I can't see any scenarios where people or environments will be adversely impacted if there are a few classes that are not used in a particular configuration. There might be an issue if those extra classes drag in extra 3rd party dependencies so in those cases we need to make sure things run ok without the extra dependencies. In this case though there are no extra dependencies over whats in the base-runtime so its fine. The flip side of this is that by merging the modules it makes it vastly simpler to use as you just need the single runtime jar and no worrying about what there for of if you need things like tuscany-web-javascript, tuscany-web-javascript-dojo, tuscany-implementation-widget-runtime-dojo etc. For 2.0 I think we need to make sure all the extensions have a default configuration that works ok for most situations with just the extension's single runtime jar. ...ant
