some questions and comments about aura HOT 9 CLOSED

I'd love to see answers to these questions as well. I'll add one more to the list:

Looking at Google's calendar application, there are a handful of "widgets" on the screen. There's the actual calendar as well as a list of calendars, a list of tasks, etc. Are each of these widgets independent modules that communicate over pub-sub, or would these all belong to the same module? I'm inclined to believe they would all be one module because they share a set of common data. However, Nicolas Zakas' Twitter example makes me think they should be separate.

from aura.

@bradgignac In that example (or at least, in the way that Aura considers it) those widgets would be separate. You ideally want each unique "piece" of functionality to be able to exist on its own or exist with other widgets on the same page. Now those widgets could be developed by more than just one person. There could be teams working on them and communication over pub/sub would make sense. You just let the rest of the page know that there's something interesting happening with your widget, perhaps share data related to that and it should all just work.

from aura.

@git-andersch

1. This should be fixed
2. I opted for the name widgets because I didn't want to confuse developers. We already have application level modules in the form of AMD modules in the application and calling bundles (some people call these modules, others widgets) modules would have probably raised more questions.
3. We could probably do a better job of improving naming in this case. I personally prefer referring to the pieces of the architecture by their pattern names, but in the case of facade and sandbox, wanted to keep sandbox in place because people will have read Nicholas' work and may not have been able to find the correct piece. Maybe we should just rename the parts core.js, sandbox.js and permissions.js.
4. I completely agree. I've started work on doing just this. At the moment the Backbone-specific part of the project is really implemented as a set of extensions but its part of the demo app. Would you also like to see this separated? Aura is now separate from the demo.
5. Im still forming opinions about this because I tend to believe that dynamic stylesheet loading can come with its own set of problems and should be avoided. Technically, you're right. We consider templates a part of a page and so, stylesheets should be too.
6. You can easily switch on or off parts of a page, configure them without having to touch widget code directly.
7. Could you go into this in a little more detail? Not sure I follow. Do you mean permissions for each component or just the ability to extend?
8. This is something we're going to be addressing in the intermodule communications rewrite Im working on at the moment. It was in part something required for the demo which may not find its way into the final version of the library.
9. What would you like to be able to configure specifically?
10. I would approach those the same way I would in a normal RequireJS project which is to say, common pieces should be placed somewhere shared (e.g /shared) where other widgets can access them and just pull them in as dependencies. I see that as being more a file-layer concern, but correct me if I've misunderstood.

from aura.

@addyosmani It seems like there is a use case for submodules (or subwidgets). I'll continue using Google's apps as an example. If they were one large application, you would have several global modules - navigation, chat, notifications, account settings. When a navigation item was clicked, a corresponding module would be started (mail, calendar, docs). Mail would be composed of a number of its own submodules (folder list, email list, mail settings).

Does this make sense, or would it be better for all of these to be top-level modules that are started when the mail navigation item is clicked? I know that you are very busy so I appreciate your help!

from aura.

@bradgignac I think you're right in that there's a need for sub-widgets. I don't think this is something that would necessarily be taken care of at a framework level, but one could create sub-widget instances (based on the current widget concept) that communicate with each other via pub/sub and are just wrapped in a higher level module grouper. Does that make sense?

Long term, I would love to create an iGoogle/Google apps style demo that showcases how these concepts could be implemented with Aura.

from aura.

@addyosmani

1. Perfect
2. That makes sense. Would be nice if the developer could configure his preference.
3. I think it is easier to understand when the file- and reference-name are the same.
4. Cool, haven't seen that yet. You also seperated the Backbone-specific part - nice!
5. Depends on which browsers you want to support. Maybe there are better solutions if you integrate LESS? Technically it would be very nice.
6. Ok. I think "permission" is a little confusing. In my opinion this should go under configuration.
7. Just the ability to extend. Now you have to extend the core like this:
   var mediator = Object.create(core); mediator.extension = 'xy';
   and you can extend the permissions like this:
   permissions.extend({ extension: 'xy' });
   I'd prefer a common solution like this:
   core.extend({ extension: 'xy' });
   also you can move the object.create function to aura (which would be a better place in my opinion)
8. Ok
9. It would be nice to customize paths/directories, naming (widgets/modules) and define the things you did in permissions.js as a first part, but I'm sure there will be more in the future.
10. Ok

from aura.

@git-andersch

1. Good feedback
2. Agreed, I like the consistency but they do different things. The permissions.extend method is not prototypal. It just does a shallow copy of properties from one object to another. I'm wondering if prototypal inheritance would actually work fine for permissions though.

from aura.

@dustinboston

Of course. But the implementation of extend for the core and the sandbox can be prototypal.
Now that you guys are merging the mediator, sandbox and permissions into one file it can be done like in Backbone:
https://github.com/documentcloud/backbone/blob/master/backbone.js#L1310

from aura.

The new version of Aura that we have landed in master will attempt to address as much community feedback as possible, where that feedback has been overlapping and been in demand. Closing as this issue is about 0.9.x

from aura.