Proposal: Remove TemplateView/Handlebars to a View Plugin

[etgryphon]

All:

I want to start the discussion about removing TemplateView/Handlebars
from the SproutCore Codebase. It would not go away entirely, just be
a opt-in view rendering framework built on top of SC.View. This means
that people don't need to use it if they don't want to.

Pros:
- Reduce Code Size
- Don't force the TemplateView paradigm

Cons:
- Abstracts the TemplateView from the View Layer

Post Comments...

[Kyle Carriedo]

+1 I agree

Kyle Carriedo

[Chad Eubanks]

+1

Chad Eubanks

Sent from my iPhone

[Maurits Lamers]

Seems to be a good idea, though there is one problem: in order to make templates work, there have been some changes to the bindings.
Should these also be pulled out? If yes, how will the template layer be made to work?

[etgryphon]

Honestly, the correct way to do it is actually to precompile the
templates into SC.Views with the buildtools and then we can just use
them normally. That way all the benefits of SC.Views and bindings
will work normally. At least that is what, I think is the best.

On Dec 12, 12:35 pm, Maurits Lamers <mauritslam...@gmail.com> wrote:
> Seems to be a good idea, though there is one problem: in order to make templates work, there have been some changes to the bindings.
> Should these also be pulled out? If yes, how will the template layer be made to work?
>
> Op 12 dec 2011, om 18:29 heeft Kyle Carriedo het volgende geschreven:
>
>
>
>
>
>
>
> > +1 I agree
>
> > Kyle Carriedo
>

[Topher Fangio]

I am in favor of removing/moving the TemplateView to simplify/standardize, however, one of the main reasons that I used it was so that I could more easily render list views with unknown heights. I would love to replace my current TemplateViews with another solution, but I couldn't find one that worked very well.

So, I would say this: if we remove/move TemplateView, it would be good to have a clear and documented way that Sproutcore can accomplish similar things with the existing code. Since I doubt it was used heavily, I doubt that we need a full "Porting from 1.6 to 1.7" guide or something like that, but some documentation would be good. If I had help with the solution, I would certainly be willing to write the guide showing others how to do it.

--

Topher Fangio

System Architect
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141

[Juan Camilo Pinzón]

Agree with Maurits. I have no problem moving it out (not removing it), but I think is not as simple as moving files. It would need somebody with enough knowledge and plenty of baking time.

TemplateViews fill a gap that SC always had and it does a great job at it. As Topher mentioned is a great solution when stuff like collection view doesn't fit the requirements or it's too heavy.

You just have to be smart about when to use traditional SC.Views or Template views. 

[Topher Fangio]

Perhaps, then, we should also consider renaming it.

And honestly, the "template" functionality isn't as useful to me as the "more basic view" functionality is. In fact, I ran into a lot of problems trying to get Handlebars to do what I wanted it to. I even switched some of my views to use EJS templates because it made more sense to me and was drastically easier to manage.

I like the theory of a "logic-less" template, but in reality, sometimes being able to write and call a Javascript function is really useful.

--

Topher Fangio

System Architect
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141

2011/12/12 Juan Camilo Pinzón <jua...@gmail.com>

[Tyler Keating]

+1.  I would like it if each view system was modularized properly so that we could work with one, both or neither.  This would make it easier to introduce an entirely new optional view system, like the Canvas based one that Erich has proposed, without forcing anyone to abandon the current systems.  Since SC.View and SC.TemplateView are both extensions of SC.CoreView, I think we're already on the right path and it seems like modularizing SC.TemplateView first is the best step.  

Anecdotally, I'm bringing TemplateViews higher up the view chain more and more each day.  So I would be one of the people interested in supporting that sub-framework/sub-project.

For reference, there's a similar discussion here: https://github.com/sproutcore/sproutcore/issues/635 

-- 
Tyler Keating

[etgryphon]

Mike Ball has already done the work to kill Handlebars in SC...https://
github.com/sproutcore/sproutcore/pull/643

Topher:

You can get that same functionality with the normal view system, by
implementing SC.CollectionRowDelegate...I think the API needs to be
improved a little...like adding a property-like
'hasContentDefinedRowHeight' to trigger fully custom row height calls.

Evin

On Dec 12, 1:35 pm, Tyler Keating <ty...@sproutcore.com> wrote:
> +1.  I would like it if each view system was modularized properly so that we could work with one, both or neither.  This would make it easier to introduce an entirely new optional view system, like the Canvas based one that Erich has proposed, without forcing anyone to abandon the current systems.  Since SC.View and SC.TemplateView are both extensions of SC.CoreView, I think we're already on the right path and it seems like modularizing SC.TemplateView first is the best step.
>
> Anecdotally, I'm bringing TemplateViews higher up the view chain more and more each day.  So I would be one of the people interested in supporting that sub-framework/sub-project.
>
> For reference, there's a similar discussion here:https://github.com/sproutcore/sproutcore/issues/635
>
> --
> Tyler Keating
>
>
>
>
>
>
>
> On Monday, December 12, 2011 at 12:01 PM, Juan Camilo Pinzón wrote:
> > Agree with Maurits. I have no problem moving it out (not removing it), but I think is not as simple as moving files. It would need somebody with enough knowledge and plenty of baking time.
>
> > TemplateViews fill a gap that SC always had and it does a great job at it. As Topher mentioned is a great solution when stuff like collection view doesn't fit the requirements or it's too heavy.
>
> > You just have to be smart about when to use traditional SC.Views or Template views.
>
> > On Dec 12, 2011, at 9:41 AM, Topher Fangio wrote:
> > > I am in favor of removing/moving the TemplateView to simplify/standardize, however, one of the main reasons that I used it was so that I could more easily render list views with unknown heights. I would love to replace my current TemplateViews with another solution, but I couldn't find one that worked very well.
>
> > > So, I would say this: if we remove/move TemplateView, it would be good to have a clear and documented way that Sproutcore can accomplish similar things with the existing code. Since I doubt it was used heavily, I doubt that we need a full "Porting from 1.6 to 1.7" guide or something like that, but some documentation would be good. If I had help with the solution, I would certainly be willing to write the guide showing others how to do it.
>

> > > --Topher Fangio

>
> > > System Architect
> > > Pharos Resources
>
> > > office: 325.216.2908
> > > mobile: 325.660.7141
>

> > > On Mon, Dec 12, 2011 at 11:35 AM, Maurits Lamers <mauritslam...@gmail.com (mailto:mauritslam...@gmail.com)> wrote:
> > > > Seems to be a good idea, though there is one problem: in order to make templates work, there have been some changes to the bindings.
> > > > Should these also be pulled out? If yes, how will the template layer be made to work?
>
> > > > Op 12 dec 2011, om 18:29 heeft Kyle Carriedo het volgende geschreven:
>
> > > > > +1 I agree
>
> > > > > Kyle Carriedo
>

[Umberto Nicoletti]

+1

I also strongly suggest that the project formalizes the voting process like, for example, has been done here:

http://mapserver.org/development/rfc/ms-rfc-23.html#detailed-process

or discussions like these could go on for ever and ever.
Not that I think that discussion is bad per se, just that discussion should be distinct from voting.

In discussion anyone, even a user, can put forward ideas and proposals.

If these gather support from the maintainers in the form of votes then they can be adopted.

Umberto

[Charles Jolley]

Umberto - would you mind writing up a wiki page describing how you think the voting should work?  We could get agreement and go from there.  Good suggestion.

[Umberto Nicoletti]

No problem, I'll do that.

I will base it on the mapserver document I linked above as that's what I already have (positive) experience with.

Umberto

[Charles Jolley]

Great!  Thanks!

[Umberto Nicoletti]

Done:

https://github.com/sproutcore/sproutcore/wiki/RFC-1-:-Project-Governance