Draft Roadmap for 3.0

[mark_story]

Jose and I were recently talking about ways we could get more people involved in the development of 3.0. We decided that before we can try and get more people involved we should assemble a rough draft of what the roadmap is. We've done that and put it up on github.

https://github.com/cakephp/cakephp/wiki/3.0-Roadmap

Our hope is that by having a roadmap (even if incomplete) will help people get involved. Is there anything you see there, that we don't need to do for 3.0? Is there anything you think is missing? Is there anything you'd like to help out with?

-Mark

[bär]

First of all, thanks guys for all the work you have put onto 3.0, I already know it will be great :)

I think one thing missing would be a way to make it simpler for plugins to be configured. Right now, they can be bootstraped on demand, but there is no way to directly configure them but to make some Configure trickery in bootstrap and later some more inside the plugin so that the configuration parameters are not merged or overwritten.

With the model/behaviors layers being rewritten, I don't know if there will be a way for mangling with the options passed to the callbacks. Right now they are not passed by reference, but copied and then fired using the event system, so there is no way one can alter them and hope for them to stay that way. If I recall right, I have had many headaches and ended up using black magic whitelisting fields using behaviors + callbacks.

I think it was on the table some time ago, but why are we not using curl on 3.0?¿

--
You received this message because you are subscribed to the Google Groups "cakephp-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cakephp-core...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Ber Clausen

[mark_story]

My main reason for not using curl is availability. It is an optional module that is not always installed. The current Http/Client uses an adapter system that could easily have a ext-curl adapter added in the future. I think it might be a good thing to add in 3.1, unless someone has the time to address it now.

-Mark

[mark_story]

I've been thinking more about the roadmap and what we want to deliver for 3.0. I think it might be useful to think/list a few things that *are* not going to be part if 3.0 instead of just listing what will be in. Skipping a few things will help us keep the timeline shorter and keep code simpler fine short term. Features that are left out could be moved into plugins or added in future releases. I was thinking it would be good to leave out the following:

- lazy loading associated entities. I think this will keep the new ORM simpler, and I feel that lazy loading promotes sloppy inefficient programming that becomes a liability later in a projects life.
- schema shell and migrations. I feel this would be best handled as a plugin. The cakedc plugin is commonly used and could be updated and simplified for 3.0 instead of duplicating work.

Are the any other things we can put into plugins or defer until later?

-Mark

[Ravage84]

Yeah a "That's not going to be in there list, except maybe you make it happen yourself" list could help.

But I think another thing is also important:
In my now 3/4 years in which I worked with CakePHP (2.2+) and did some contributions to the framework, I noticed there are a lot of discussions about BC. The loved and hated back compatibility...

For a framework BC is very important because you don't want to break the apps of your user base if not totally necessary. This ensures that developers can rely with confidence in your "product" during its whole lifecycle which can - and most often will - span over many years.

And because of this I think less is more (yeah, once more).
What should be in the first release of a new major version is a stable and well thought-through base, that will be the fundament for all future minor releases. At the same time it should hold the core vision of what you want to achieve within its lifespan.

With a stable and well thought-through base I also specifically mean the (public) API.
One not so well thought-through implementation during the the development of the initial release of a coming major release can impact the whole lifecycle of this major. One feature which you are not so fond of anymore once some time passed, you very likely have to support during the whole lifetime of the new major. If you want or not.

So what I want to encourage you here, is to think everything you put into 3.0 very well through and don't be shy to say "no" or may be "not yet".
Everything that can be build on top of this stable base - as plugin or as core contribution - can and probably should be build that way.

In love with the cake
Marc

[James Watts]

http://en.wikipedia.org/wiki/Technical_debt

I couldn't agree with you more :)

This email may contain material that is confidential, privileged and/or work product for the sole use of the intended recipient.  Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited.  If you are not the intended recipient, please contact the sender and delete all copies.

Cake Development Corporation.

[Reuben Helms]

With regards to the FormHelper, could something be done to all individual form elements to be extensible?

Using templates for the output is a start, but I've had, on occasion, the need to extend a form element to create a new type, and the result has been an extension of the FormHelper, but with way too much copy and paste from the FormHelper source to aid with integration.

For example, in one project, I created: 

* a dateTime type that would work as a plain text field, and the jQuery UI date picker, 

* an image type that would display a file input and output the image that was already selected for the field, 

* a media image library type to display a select list of images, and provide a link to add new images

* a media image type to upload a file to a media library and provide a preview of the existing image

* a change have model fields with varchar(max) recognised as textarea

It was easy to add new methods for the new types, but to get these types used when calling $this->Form->input required a little more copy and paste from the original FormHelper::input than should have need necessary.  That was my thought at the time, and this was with CakePHP 1.3 many moons ago.  Unfortunately, the client hasn't required any major updates that would warrant an upgrade to CakePHP 2.x, but I don't think the FormHelper has changed significantly in CakePHP 2.x.

Regards

Reuben Helms

[mark_story]

Reuben: I'm just starting to think about formhelper, and I agree it would be nice to have a more extensible type system that allows developers to add/replace types. Once I get the wiki page I'm working on in decent shape I'll certainly share it here as forms are a hugely important part of any web app.

-Mark

[Saleh Souzanchi]

@mark : Is not it better FromHelper and HtmlHelper to be implemented decoration pattern?

     Best Regards
   Saleh  Sozanchi
 * * * * * * * * * * * * *

Mobile : +98 918 111 7209

Phone : +98 811 823 4448

http://soozanchi.ir
http://cakephp.ir

On Thu, Oct 10, 2013 at 6:44 AM, mark_story <mark....@gmail.com> wrote:

Reuben: I'm just starting to think about formhelper, and I agree it would be nice to have a more extensible type system that allows developers to add/replace types. Once I get the wiki page I'm working on in decent shape I'll certainly share it here as forms are a hugely important part of any web app.

-Mark

[mark_story]

Saleh: Perhaps, but every decorator implementation I've seen to generate HTML is either really verbose, or really slow or both. String templates have the benefit of being both terse and efficient. But if you have something in mind it is worth discussing.

-Mark

[bär]

About FormHelper,

I think having multiple forms inside a view is something very common nowadays, but in 2.x attaching Security component to them always invalidates all the forms when one of them is 'consumed'. This happens when the forms are created at the same time for the same view, of course. Do you have something planned like having the nonce calculated/invalidated per form?

On a side (but somewhat related) topic, will the creation of multiple forms using the same model be in the road map? I believe It has been a recurrent request since 1.2.

--
Ber Clausen

[Saleh Souzanchi]

On Fri, Oct 11, 2013 at 4:44 AM, mark_story <mark....@gmail.com> wrote:

Perhaps

​Mark :  I agree with you on a slow 5.2, but 5.4 is too slow?

 A year ago I would've changed as follows:
https://gist.github.com/zoghal/83d0c216c10fbaa8999b

This is just an idea.
​
And a proposal for the development FormHelper:

Implementation techniques used in laravel:
http://laravel.com/docs/html # custom-macros

[James Watts]

Saleh, that's actually already available for CakePHP in a sense using the Cake Toolkit (https://github.com/jameswatts/cake-toolkit), which at CakeDC we've already rolled out with some large scale and enterprise applications which needed that level of abstraction and extensibility. Specifically, you can see how the HtmlHelper is provided as an object factory here - https://github.com/jameswatts/cake-factory - and we also have our own Bootstrap factory in-house.

I've also been working on a markup based approach with provides more or less the same level of abstraction (https://github.com/jameswatts/cake-markup-language), although it forfeits the power in the object-orientated approach of CTK. The overall benefit being that the view layer is better managed as a read-only layer, and avoids the logic and business processing people inadvertently apply there, as well as that nasty procedural PHP code.

[mark_story]

If you need to submit multiple forms, or the same form multiple times you should be using shared CSRF tokens, which gets around this issue. I'm pretty sure shared CSRF tokens have been around since at least 2.1.

What are the current limitations around making multiple forms for the same model?

-Mark

[mark_story]

I've not done any performance testing in 5.4 around generating HTML using decorators. I've always felt that creating an object for each HTML element is clumsy and generally not necessary.

The laravel API is very similar to what we already have. I like the ability to add custom macros, that is something that will be included in the new FormHelper. I'm hoping to use 'macros' or 'input types' to generate many of the more complex internal types like datetime pickers, and select boxes.

-Mark

[bär]

Do you mean setting SecurityComponent::$csrfUseOnce to false?¿ Most of the web is turning to AJAXish behaviors, reducing data for requests, and so on; it is common to create multiple forms (a la facebook settings), and POSTing the information using javascript. The idea was creating multiple forms, and sending them via AJAX, so that _each_one_ of them maintains its own nonce (or extra security information), without the security loss of keeping a token reused (until expiration at least). I don know if the Form helper / Security component will have a face lift big enough to have this in consideration, but it worth a try.

Last time I checked, you were not able to call Form->create() more than once per view using the same model, pointed to the same controller/action; e.g. /login screen with both a login & signup forms looping in the same controller/action [1].

[1] https://www.google.com/search?q=cakephp+multiple+forms+same+model

--

You received this message because you are subscribed to the Google Groups "cakephp-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cakephp-core...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Ber Clausen

[mark_story]

Yes I was referring to use once = false. As you said with more applications relying on asynchronous features, managing single use csrf tokens becomes very painful. I honestly think per session tokens are simpler to use, more efficient, and don't reduce security very much. Interestingly, both django and rails default to per session csrf tokens stored in cookies. I think that might be an approach we should explore as well.

-Mark