Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[View] Coarse-grained view options #58

Closed
sebez opened this issue Dec 11, 2014 · 5 comments
Closed

[View] Coarse-grained view options #58

sebez opened this issue Dec 11, 2014 · 5 comments
Assignees

Comments

@sebez
Copy link
Contributor

sebez commented Dec 11, 2014

(already discussed with @pierr )

Currently, the Focus standard views complies with our needs, but I have the feeling that there is too much to do to obtain the wished result.

As already documented, we can implement our ergonomic templates by setting the right set of options in the views.

For instance :

Read-only simple detail

customOptions:{
  isEdit:false,
  isEditMode: false
} 

Read-Write simple detail

customOptions:{
  isEdit:true,
  isEditMode: true,
  isNavigationOnSave: false
} 

We need to be able to define in a single place, named sets of options for each ergonomic patterns, that can be referenced in the views declaration.

In the views, we would use the pattern name in place of the custom options.

This would allow to implement views with less verbosity and more semantics.

Read-only simple detail

pattern : patterns.readOnlyDetail

Read-write simple detail

pattern : patterns.readWriteDetail

Note : of course we should keep the custom options API, that would allow to override specific flags of the patterns.

@pierr
Copy link
Contributor

pierr commented Dec 11, 2014

As for now, just stay with the customOptions, and I agree on the fact that most commons options shoud be referenced somewhere", it is in this gist and reference in the doc.

Adding these options in a file name pattern or pagePattern is indded the idea. But inside the view, I think that

View.extend({
  customOptions: pagePattern.readOnlyDetail
});

is enough. It allows us to stay with one entry point and certainly ease the development.

@pierr
Copy link
Contributor

pierr commented Dec 11, 2014

But the pattern or whatever its name is shoud be added in focus

@pierr pierr added this to the v0.2.2 - Bug and pagination milestone Dec 11, 2014
@pierr pierr self-assigned this Dec 11, 2014
@sebez
Copy link
Contributor Author

sebez commented Dec 11, 2014

Fair enough, we'll do that :

  • declare in the project the set of page patterns
  • use it directly in customOptions
  • if we need specific override, we'll use an extend idiom :
View.extend({
  customOptions: _.extend({}, pagePattern.readOnlyDetail, {dummy:true})
});

Thank you.

@pierr
Copy link
Contributor

pierr commented Dec 11, 2014

It makes me think that a _.combine(obj1,obj2) wich is a shortcut for _.extend({}, obj1, obj2) could be usefull, we use it really often.

@sebez
Copy link
Contributor Author

sebez commented Dec 11, 2014

Good advice, thank you.

@pierr pierr modified the milestones: Views Helpers refactoring, v0.2.2 - Bug and pagination Jan 15, 2015
@sebez sebez removed this from the Views Helpers refactoring milestone Jan 15, 2015
@pierr pierr closed this as completed Jun 30, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants