Retire JsHelper in 3.0

[ADmad]

I think JsHelper has outlived its usefulness. It's simply a crutch for newbies. Any experienced dev would rather use a js lib of their choice directly. Removing the helper would stop making newbies dependent on it initially just to realize down that line that it has very limited features. So my vote is to simply remove the helper and related engines and trim down the code we need to maintain for a small minority.

All those in favor say aye. All those against better come up with a very strong argument to keep it :)

[José Lorenzo Rodríguez]

Aye

[Thiago Belem]

Aye, captain!

[William Golden]

Aye for me

On Sep 30, 2012 9:57 AM, "Thiago Belem" <thiago.b...@gmail.com> wrote:

Aye, captain!

[Saleh Souzanchi]

+1

[Carlos Gant]

aye

[Cauan Cabral]

aye

[Juan Basso]

Aye

[Vitor Pacheco]

unanimity?

2012/9/30 Juan Basso <jrb...@gmail.com>

Aye

--
Vitor Pacheco
Skype: vitor.pacheco.costa
Msn: vito...@hotmail.com

GTalk: vitor...@gmail.com
Cel.: 71 8626-7909
Tel.: 71 3378-5778 / 71 3287-3475

[mark_story]

I agree its probably not very useful anymore, and one of its nicest features (script buffering) is easily accomplished through view blocks.  My only worry in removing it is people complaining about no easy way to do ajax pagination.  This could easily solved with an example in the cookbook using some simple jQuery.  Removing the JsHelper also simplifies parts of the PaginatorHelper as there is a moderate amount of code there that will also be removable.

-Mark

[ADmad]

It's settled then, JsHelper goes. I will put it on my TODO list.

[bär]

3/4 aye here!

I think JsHelper should be left aside too, but some functionality
should stay. I consider (a) buffering and (b) AJAXish (plus
pagination) functions somewhat usefull most of the time.

a. In fact, I consider this one an added value.
b. DRY is the key here, Many applications today, use AJAX or AHAH
techniques heavily, and I think functions like request() are nice to
have around.

I hope Asset Compress sleeps in the core in 3.0 :)

--
Ber Clausen

[ADmad]

I think JsHelper should be left aside too, but some functionality
should stay. I consider (a) buffering and (b) AJAXish (plus
pagination) functions somewhat usefull most of the time.

a. In fact, I consider this one an added value.

Yes buffer() was the only feature I used too, but its no longer required as same can be achieved using view blocks now.

 

b. DRY is the key here, Many applications today, use AJAX or AHAH
techniques heavily, and I think functions like request() are nice to
have around.

You can easily write DRY js code too, jquery plugins ftw.

JsBaseEngine::request() is just wrapper for $.ajax() so just use that or the other convenience functions for ajax.

Mark mentioned that ajax pagination was another useful convenience, which can be achieved with just 2 lines of jquery:

$("#paging").on("click", "a", function() {

$("#content").load(this.href);

});

 

I hope Asset Compress sleeps in the core in 3.0 :)

Imo its fine as a separate plugin, makes maintenance easier.

Perhaps the only thing required is moving it under CakePHP account like DebugKit.

[AD7six]

aye

Examples in the book - or even a repo so you could load/point at individual snippets - are the way to go imo.

AD

[mark_story]

I won't be merging AssetCompress into CakePHP anytime soon.  I still think keeping CakePHP lean is important, and AssetCompress works great as a plugin.

-Mark

[William Golden]

I agree with that Mark, I think keeping the core lean, but having solid plugins available is a good move.

Perhaps, though, we could add these standard plugins to the documentation? (if they are not already)

- William Golden

[euromark]

for those who might cry tears about the helper being removed.

it could also be made available in the future via plugin

or just added to the utils plugin etc.

and all the work put into it would not be totally wasted :)

[Graham Weldon]

Dare I suggest, as we have with other features departing the core, that we plugin-ify this as a core plugin, much like the datasources of old?

That way, those that rely on it (and there are those that do) can continue to use it, assist with it or build on it as necessary while we focus on the core.

I'd be more than happy to help out transitioning this to a plugin.

Cheers,
Graham Weldon
http://grahamweldon.com
e. gra...@grahamweldon.com
p. (+61) 0407 017 293

Skype: grahamweldon

[bär]

On Mon, Oct 1, 2012 at 2:46 AM, ADmad <admad...@gmail.com> wrote:
>>
>> I think JsHelper should be left aside too, but some functionality
>> should stay. I consider (a) buffering and (b) AJAXish (plus
>> pagination) functions somewhat usefull most of the time.
>>
>> a. In fact, I consider this one an added value.
>
> Yes buffer() was the only feature I used too, but its no longer required as
> same can be achieved using view blocks now.

Yup, I read what Mark said, and I noticed the same thing :P

>> b. DRY is the key here, Many applications today, use AJAX or AHAH
>> techniques heavily, and I think functions like request() are nice to
>> have around.
>
> You can easily write DRY js code too, jquery plugins ftw.
> JsBaseEngine::request() is just wrapper for $.ajax() so just use that or the
> other convenience functions for ajax.
>
> Mark mentioned that ajax pagination was another useful convenience, which
> can be achieved with just 2 lines of jquery:
> $("#paging").on("click", "a", function() {
> $("#content").load(this.href);
> });

Speaking of not repeating code, I know it is fairly easy to build this
kind of js pagination scripts where the only variables could be some
short strings, the selectors and the URI. But, to speak the truth, the
only _convenient_ method I can miss is request(), which can not be so
easily replicated in a DRY way with view blocks; where you have to
consider the magic provided by _parseOptions(), _prepareCallbacks()
and _mapOptions() safe functions.

>> I hope Asset Compress sleeps in the core in 3.0 :)
>
> Imo its fine as a separate plugin, makes maintenance easier.
> Perhaps the only thing required is moving it under CakePHP account like
> DebugKit.

Yeah! I meant for it to be in the cakephp github account, not inside
the core codebase, sorry for the misunderstanding.

--
Ber Clausen

[bär]

>> I won't be merging AssetCompress into CakePHP anytime soon. I still think
>> keeping CakePHP lean is important, and AssetCompress works great as a
>> plugin.

[snip]

On Mon, Oct 1, 2012 at 1:29 PM, William Golden <egde...@gmail.com> wrote:
> I agree with that Mark, I think keeping the core lean, but having solid
> plugins available is a good move.
>
> Perhaps, though, we could add these standard plugins to the documentation?
> (if they are not already)

Can't agree more.

--
Ber Clausen

[mark_story]

Admad:  Since you've taken it upon yourself to banish the JsHelper could you put it into a new repo/plugin as well?

-Mark

[mark_story]

There isn't a place in the documentation currently for 'standard' plugins, but we could always make a short list of frequently used plugins.  My main fear with maintaining a short list is it will quickly become a mess and deciding what plugins make it onto the short list becomes a hassle as well.

I feel like a better solution for promoting standard plugins could come from plugins.cakephp.org.  Let the community vote and maintain the list of recommended plugins.  It removes any bickering about what is and isn't a standard plugin.

-Mark

[ADmad]

Admad:  Since you've taken it upon yourself to banish the JsHelper could you put it into a new repo/plugin as well?

I did take it upon myself to banish it but Graham volunteered to salvage it into a plugin :)

I agree with you about not adding a "standard" plugins section in the manual and instead using plugins.cakephp.org and let the community vote/recommend.

[José Lorenzo]

Can we at least put cakephp official plugins in the documentation? I had this idea a few days ago about adding another "traffic light" in default bake homepage checking for DebugKit, it might definitely increase the awareness of the plugin, I'm always surprised by how few actually use it.

[mark_story]

We could, some of them like ApiGenerator are not generally useful to people. But other like DebugKit are.  I'm fine with including plugins in the cakephp organization as there aren't many, and there is nothing to argue about :)

-Mark