it would be nice to see at least one example with multiple controllers

Question

it would be nice to see at least one example with multiple controllers

aaronksaunders opened this issue 13 years ago · 13 comments

aaronksaunders commented 13 years ago

or is the assumption that we are buildiing apps with all functionality in one controller? or is it just not there yet?

either way a sample would be appreciated

thx

Answer 1 · 2012-06-24T05:26:16.000Z

The masterdetail sample under alloy/test/apps shows multiple controllers.

Answer 2 · 2012-06-24T06:39:44.000Z

Thank you, I tool a look... but there is not a single line of documentation explaining what is going on? If you have an answer or can explain what is going on, how the controllers are interacting, it would be appreciated.

thanks in advance

Answer 3 · 2012-06-24T14:00:24.000Z

@aaronksaunders, as you well know, in the early stages of projects like these, documentation is a moving target as so much is constantly changing. That said, I'll go back and comment the hell out of that masterdetail sample so it's clear how the interaction works.

Answer 4 · 2012-06-24T14:12:44.000Z

I don't need a lot of comments, I just think that a sentence or two to help connect the dots on the read me would be helpful

Sent from my iPhone

On Jun 24, 2012, at 10:00 AM, Tony Lukasavagereply@reply.github.com wrote:

@aaronksaunders, as you well know, in the early stages of projects like these, documentation is a moving target as so much is constantly changing. That said, I'll go back and comment the hell out of that masterdetail sample so it's clear how the interaction works.

Reply to this email directly or view it on GitHub:
#19 (comment)

Answer 5 · 2012-06-24T16:25:39.000Z

Every sample in test/apps has its own README.md which should explain at a high level what's going on. This is the one for the masterdetail: https://github.com/appcelerator/alloy/blob/master/test/apps/masterdetail/README.md

Is there something in particular that is unclear that is not covered in the README.md?

Answer 6 · 2012-06-24T16:48:26.000Z

Don't worry about it, I will wait until it gets further along… I guess if it was clear from the read me I wouldn't have asked for a clearer explanation :-)

I guess I thought the purpose of releasing it was to give feedback. I don't expect perfect documentation, but I think I am pretty advanced and I am struggling to understand the basic concepts here. You guys are in the code deep so you have a different perspective on the code and the documentation.

There are many way to implement and architect view to controller and controller to controller interaction, IMHO it is not clear from the samples or the code in the readme, how it all hangs together. I guess I could play with it more to try and pull it together… but from my initial pass it just wasn't clear.

Like I said, don't worry about it, I will hold off until you guys have more time to focus on documentation and clearer samples.

Aaron K. Saunders

Founder and CTO

Clearly Innovative, Inc.

a (mailto:bmaxwell@appcelerator.com)aron@clearlyinnovative.com

O: (202) 683-7495

M: (201) 214-5926

http://www.c (http://www.appcelerator.com/)learlyinnovative.com

An Appcelerator Titanium Gold Partner

On Sunday, June 24, 2012 at 12:25 PM, Tony Lukasavage wrote:

Every sample in test/apps has its own README.md which should explain at a high level what's going on. This is the one for the masterdetail: https://github.com/appcelerator/alloy/blob/master/test/apps/masterdetail/README.md

Is there something in particular that is unclear that is not covered in the README.md (http://README.md)?

Reply to this email directly or view it on GitHub:
#19 (comment)

Answer 7 · 2012-06-24T17:07:44.000Z

@aaronksaunders - you already have provided good feedback we need to put better documentation in the sample code, and more samples around a particular topic we can take care of that and I'm working with our documentation team to start to integrate Alloy into Titanium docs. It's of course your decision but if you could take a look at master detail and bang on it bit, it should build and run and then give us feedback on what was not clear and what samples we could do to help clarify the sample.

Answer 8 · 2012-06-24T17:12:24.000Z

I will take a look and when I get it figured out, I will let you know the area where I was confused and what I think would clarify the documentation… I guess until I understand I cannot provide better feedback.

but thanks for taking the time to respond and thanks for the framework, it looks interesting.

BTW why is the approach for extending the models based on adapters and not creating a doa for a specific model? I this is a separate question, I am happy to add an issue to the repo.

Once again thanks

Answer 9 · 2012-06-24T17:32:59.000Z

Thanks in advance for working with Alloy and helping us out. We use Backbone as our middle tier server and it has an overridable sync method that allows us to plugin CRUD adapters like filesystem, sql, cloud (ACS) we can pull in the adaptors from our model description along with any user defined processes like attribute validation so in a nut shell it was a natural fit. We are open to other ways to do this as well so if you like open a separate issue and we can explore Alloy and MVC more it's key component in Alloy so I want to make sure we get it right.

Answer 10 · 2012-06-24T19:22:49.000Z

@aaronksaunders, the idea is that each view has a corresponding controller. The 2 are dynamically turned into a single "component object" at compile time. These generated components objects are encapsulated in commonjs modules and placed in the Resources/alloy/components path for use at runtime.

In the case of the masterdetail sample, the index "component object" does nothing more than generate instances of the master and the detail, as seen in the very sparse index.ml file. These instances are not opened or used until something in the index.js controller actually acts on them. In the case of this index.js, the 2 top-level windows (master & detail) are accessible by their IDs via the component object.

The component object is accessible in every controller via the $ symbol. Each controller is only aware of its own elements declared in its corresponding view. So for multiple component objects to communicate with each other, you'll need to either use custom events on the component object, or expose an interface of function and properties on that component object.
In the case of the masterdetail, the master fires a rowClick event so that the index.js controller can act as a delegate to pass changes in the master to the detail. The detail is updated via its exposed updateContent() function.

You're absolutely right that we're too deep in it to see the confusing sections. Please, keep pushing us for this type of info. I'm sure the above doesn't clear up everything, but hopefully it fills in some of the holes. Let me know if there's additional info you need.

Answer 11 · 2012-06-25T11:44:41.000Z

Thanks. The missing link to me was that the view and controller are collapsed down into one commonjs module and that click events are used for communications.

I think understanding the magic code that is generated at compile time will help to make the overall concepts clearer

Will take another go at it this week and see what I come up with

Sent from my iPhone

On Jun 24, 2012, at 3:22 PM, Tony Lukasavagereply@reply.github.com wrote:

@aaronksaunders, the idea is that each view has a corresponding controller. The 2 are dynamically turned into a single "component object" at compile time. These generated components objects are encapsulated in commonjs modules and placed in the Resources/alloy/components path for use at runtime.

In the case of the masterdetail sample, the index "component object" does nothing more than generate instances of the master and the detail, as seen in the very sparse index.ml file. These instances are not opened or used until something in the index.js controller actually acts on them. In the case of this index.js, the 2 top-level windows (master & detail) are accessible by their IDs via the component object.

The component object is accessible in every controller via the $ symbol. Each controller is only aware of its own elements declared in its corresponding view. So for multiple component objects to communicate with each other, you'll need to either use custom events on the component object, or expose an interface of function and properties on that component object.
In the case of the masterdetail, the master fires a rowClick event so that the index.js controller can act as a delegate to pass changes in the master to the detail. The detail is updated via its exposed updateContent() function.

You're absolutely right that we're too deep in it to see the confusing sections. Please, keep pushing us for this type of info. I'm sure the above doesn't clear up everything, but hopefully it fills in some of the holes. Let me know if there's additional info you need.

Reply to this email directly or view it on GitHub:
#19 (comment)

Answer 12 · 2012-06-25T13:34:42.000Z

@aaronksaunders, Yeah, sorry about that. The "component object" was a modification made late last week. You're right, the "magic" needs to be demystified.

If you need any more help, you know where to find me. :)

Answer 13 · 2012-06-27T12:24:18.000Z

Closing ticket, will reopen if further discussion is necessary