Original model not updated

[ole108]

I would like agility to update the original model object I give to the factory function '$$()'.
This helps especially with big trees of agility components (e.g. Tables with hundreds of components).
I would like to have only one source of truth for the model.
I made a patch that takes the original model object instead of doing '$.extend(...)' and and throws an exception if the new model is non-empty and the model inherited from the prototype is non-empty too.
This works great for me and should save some memory at runtime.
Of course this behaviour is undesired for views and controllers.

Here is my Test-HTML:

var globalModel = { value: 'bla' };
var input = $$(globalModel,
    '<div><input type="text" data-bind="value" /> value: <span data-bind="value" /></div>', {
        'create': function() {
            // put the original value somwhere visible
            $('#message').append(globalModel.value);
        },
        'change:value': function() {
            // put the original value again
            $('#message').empty().append(globalModel.value);
            // show the original value and the value from this.model
            alert('global value: ' + globalModel.value + ', input.value: ' + this.model.get('value'));
        }
    }
);

$$.document.append(input, '#form');

Of course I would be willing to provide my patch (its quite small with two additional util functions).
But of course I am unsure if you like such a thing at all.
But for me its a plain bug since the view isn't bound to the model I provided.

[arturadib]

Hi, thanks for bringing this up.

Right now Agility assumes your model lives inside Agility objects. This assumption works well for most things I can think of, but of course not all possible scenarios.

Can you please elaborate on your application/use case?

[ole108]

Hi, thanks for asking. :-)

Background:
We are using Agility to create highly dynamic web pages.
So we really have a quite big model describing the whole page with generic components I have built.
Every generic component gets its part of the model. So we easily have 100 components on the page.

Use cases:
Right now we would like to exchange the whole big model with the server.
This might be possible without a patch with the persist plugin. I haven't tested it so far.

On the more hypothetical side I can imagine that the components have to interact with each other somehow.
On the purely philosophical side I have a bad feeling watching my nice big model being ripped into lots of tiny models by the components. Plus these models get all inconsistent with each other over time.
On the hacker side the copying costs memory and CPU power.

At least for this month I don't think I will be able to work further on this part of the architecture.
So it will take some time until I am able to name a really important use case.
Thus this bug is so far more for food for thought and philisophical reasons. :-)
It might become more urgent in the future.

Best regards,

Ole

[arturadib]

Hi there, I can start to imagine what your use case would look like.

So what you're saying is that your model is so big that you want
"sub-views" for different parts of the model, but at the same time you
want to update the whole thing on the server side? In other words, you
need many agility objects whose models are sub-parts of a big model?

By the way, are you using Agility in production already? If so, would
you mind if we featured your product in our agilityjs.com Gallery
page?

Thanks!

On Fri, Dec 9, 2011 at 7:24 AM, ole108
[email protected]
wrote:

Hi, thanks for asking. :-)

Background:
We are using Agility to create highly dynamic web pages.
So we really have a quite big model describing the whole page with generic components I have built.
Every generic component gets its part of the model. So we easily have 100 components on the page.

Use cases:
Right now we would like to exchange the whole big model with the server.
This might be possible without a patch with the persist plugin. I haven't tested it so far.

On the more hypothetical side I can imagine that the components have to interact with each other somehow.
On the purely philosophical side I have a bad feeling watching my nice big model being ripped into lots of tiny models by the components. Plus these models get all inconsistent with each other over time.
On the hacker side the copying costs memory and CPU power.

At least for this month I don't think I will be able to work further on this part of the architecture.
So it will take some time until I am able to name a really important use case.
Thus this bug is so far more for food for thought and philisophical reasons. :-)
It might become more urgent in the future.

Best regards,

Ole

---

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

[ole108]

Hi,

so far I have only a small spike. I can't continue work on it right now.
We will decide until (probably) end of January how to go on.

I have 2 typical use cases:
A list page with a (large) table as the central component.
This table consists of head and body and those of rows and cells.
The cells finally contain components like links to the edit page, or just text or even input fields.
I don't know how to build a table with dynamic rows and columns without lots of subcomponents.
Is there an easier way???

A dynamic form with feedback and a configurable list of inputs.
Since the number, type and order of the input fields is configurable I need to use many small components.
Is there an easier way???

The configurability of the UI is its key feature. So I can't reduce on that.
Do you know of other tools that are more suitable? Or a better way to use Agility.js?

Thanks for your help!

[arturadib]

Not really sure how to help you out here, sorry :(

Do keep me posted if you decide to go with Agility for your final product, and we can feature it in our Gallery page.