CodeIgniter 4 Deferable Features |
These are the features and issues that don't need to be resolved before we start on CodeIgniter 4 ... most will be resolved as part of the development of other features, or raised as issues/PRs during development. This thread conveys our thoughts and decisions...
We welcome your comments, but please stay on topic! This thread is about the CI4 features that we don't need decisions for until it comes time to start building that version. If you try to hijack the thread, or post non-relevant items that should be or that are dealt with elsewhere, your posts will be deleted without notice. We may post additional comments in fgeature/issue specific threads. Code generation tool: handled by tool outside of core framework. Not part of core framework. Community input: mixed. Service layer support: unclear. Seems outside CI design principles. Community input: mixed. Input filtering / form validation: beyond what we have, no. Thru third party package, easily integrated: +1. Community input: mixed. Entity models: Not ORM! might be a good idea. Community input: mixed. More base models: Might be a good idea, but better handled thru external packages. Not part of core framework. Community input: mixed. Multiple DB support: Beyond the core, no. Handle thru packages/extensions. Not part of core framework. Community input: mixed. Redo homepage design: sure. Not part of core framework. Community input: 76% in favor. Redo website design: ??. It could make sense for CI4 vs CI3. Would have to encompass forum too. Not part of core framework. Community input: 73% in favor. Conclusion: do it when closer to release. Remove index.php: Need better tutorials, not default removal. Community feedback: 51% in favor Better/more tutorials: absolutely, but not part of core framework. Community feedback: 77% in favor. Package/plugins site: good idea, but not part of core framework. Community input: overwhelmingly in favor. Target audience: everyone. Keep it simple, lean & useful. Community input: all over the map. User guide translations: awkward to accommodate. Community input: mixed. Multiple file uploads: specific issue; deal with at implementation Community input: mixed. Shopping cart support: one size doesn't suit all; use external package
James Parry
Project Lead (05-04-2015, 02:26 AM)jlp Wrote: Input filtering / form validation: beyond what we have, no. Thru third party package, easily integrated: +1. It means the validation remains strongly tied with POST variables? I am not sure this is okay... for example if we get data from an external API or from CLI or anywhere else we can't use the built in validation for these types of data... (05-05-2015, 02:06 PM)orionstar Wrote: It means the validation remains strongly tied with POST variables? I am not sure this is okay... for example if we get data from an external API or from CLI or anywhere else we can't use the built in validation for these types of data... http://www.codeigniter.com/user_guide/li...-than-post (05-05-2015, 02:27 PM)mwhitney Wrote:(05-05-2015, 02:06 PM)orionstar Wrote: It means the validation remains strongly tied with POST variables? I am not sure this is okay... for example if we get data from an external API or from CLI or anywhere else we can't use the built in validation for these types of data... Thank you for pointing out to this feature, I didn't know about it, but it's not exactly what I thought how to achieve validate data of any source: usually validation belongs to the models certain fw apply validation on setting the variable, certain validates the data on save (insert/update). Something like this is on the roadmap or discussed? (05-05-2015, 04:41 PM)orionstar Wrote: Thank you for pointing out to this feature, I didn't know about it, but it's not exactly what I thought how to achieve validate data of any source: usually validation belongs to the models certain fw apply validation on setting the variable, certain validates the data on save (insert/update). Something like this is on the roadmap or discussed? Too early to say exactly how this will work. If I recall, there was some discussion on the forums and it was pretty mixed about whether it should be controller or model or left to the developer's decision. People seem to like the flexibility of the framework and the ability to "do it my way" so I imagine it will stay a separate class. (05-05-2015, 09:26 PM)kilishan Wrote:(05-05-2015, 04:41 PM)orionstar Wrote: Thank you for pointing out to this feature, I didn't know about it, but it's not exactly what I thought how to achieve validate data of any source: usually validation belongs to the models certain fw apply validation on setting the variable, certain validates the data on save (insert/update). Something like this is on the roadmap or discussed? I like the idea about flexibility too, if I can achieve something like I mentioned above with an out of box CI, then I would be very satisfied. Thanks for your answer Lonnie!
I already validate most of my data in my models. Since most of my code is intended to work in CI 2, I just push my data into the $_POST array before I validate it. Now that I'm moving most of my code to CI 3, it's possible that I could just use the set_data() method instead.
For reference, BF_Model's validate() method: https://github.com/ci-bonfire/Bonfire/bl....php#L1145
+1 on flexible.
I prefer to validate in the model but, I wouldn't want to enforce that on others dev's nor would I want others dev's enforcing controller validation on me. I've been using the custom input other than $_POST ever since it was added to as part of the CI3 Beta's to do it "where I want". Don Myers
Input filtering / form validation
for a nice validation lib that supports arrays https://github.com/vlucas/valitron maybe could be used as inspiration
(08-27-2015, 04:14 AM)quasiperfect Wrote: Input filtering / form validation Thats kind of cool. The current system also supports arrays to though. |
Welcome Guest, Not a member yet? Register Sign In |