Well, maybe hate's a strong word. Let's say, what do you like the
least? Kind of an odd question, I know, but since we've kick-started
development of a new version, I'd like to know what the most
frustrating things with the framework are, even if they're things we
can't fix right away.
> Well, maybe hate's a strong word. Let's say, what do you like the
> least? Kind of an odd question, I know, but since we've kick-started
> development of a new version, I'd like to know what the most
> frustrating things with the framework are, even if they're things we
> can't fix right away.
On Thu, May 7, 2009 at 7:29 PM, Nate <nate.ab...@gmail.com> wrote:
> Well, maybe hate's a strong word. Let's say, what do you like the > least? Kind of an odd question, I know, but since we've kick-started > development of a new version, I'd like to know what the most > frustrating things with the framework are, even if they're things we > can't fix right away.
> I'll get us started: PHP 4 support.
Use of inflections/conventions in other languages (pt_BR).
-- MARCELO DE F. ANDRADE Belem, PA, Amazonia, Brazil Linux User #221105
> Well, maybe hate's a strong word. Let's say, what do you like the
> least? Kind of an odd question, I know, but since we've kick-started
> development of a new version, I'd like to know what the most
> frustrating things with the framework are, even if they're things we
> can't fix right away.
On Fri, May 8, 2009 at 5:55 AM, park <park....@gmail.com> wrote:
> No HABTM counterCache
> Ignoring callbacks on associative queries
> On May 8, 6:29 am, Nate <nate.ab...@gmail.com> wrote:
> > Well, maybe hate's a strong word. Let's say, what do you like the
> > least? Kind of an odd question, I know, but since we've kick-started
> > development of a new version, I'd like to know what the most
> > frustrating things with the framework are, even if they're things we
> > can't fix right away.
Inconsistency on model joining in queries
Explanation:
I might be wrong on this, please correct me if I am, but it seems like
the following:
A hasMany B hasMany C
C belongsTo B belongsTo A
If I want to get Bs where C.notAPrimaryKeyField = 'somevalue', things
work well (just contain it and we're fine). But if I want to get all
the Bs where A.notAPrimaryKeyField = 'somevalue', things break and
people die.
This logic may seem backwards (if it's a belongsTo relation, there
should be only one parent, right?), but it's not always like that.
Some databases I've worked with had to be forced into the following: a
field which defines the type of relation, let's call it "area_scope".
Then I'd have the area_id which points to different models, depending
on the value of area_scope. I think this is somewhat common in real
life databases.
That being said, the same issue exists with the relation definitions
in models with the "conditions" key. I can do this (in the Document
model):
So making conditional joins is sometimes very tricky..
* Lack of bootstrap file for plugins would be another one (possibly
even core.php and routes).
* MediaView still depends on the array of predefined MIME types (WTF?)
* Defining custom find types is is unintuitive. It should be as simple
as defining a function called _findCabbage() in your model to be able
to use find('cabbage').
* I know this probably won't happen but...: composite keys anyone?
Sometimes I have to deal with Nazi DBAs: "Artificial keys raus!". "Ich
verstehe, main Führer..."
I have also seen people complain about poor performance, and while I
didn't experience it myself, it might be worth investigating if the
complaints continue.
That's all for now.. :)
On May 8, 9:18 am, Richard <rclay...@gmail.com> wrote:
> PHP4 Support is a definite peeve.
> The Ajax helper being tied into prototype/scriptalicious - I've a preference
> for jQuery.
> Particularly like the extensive use of hashtables in cake; really, really
> like that.
> On Fri, May 8, 2009 at 5:55 AM, park <park....@gmail.com> wrote:
> > No HABTM counterCache
> > Ignoring callbacks on associative queries
> > On May 8, 6:29 am, Nate <nate.ab...@gmail.com> wrote:
> > > Well, maybe hate's a strong word. Let's say, what do you like the
> > > least? Kind of an odd question, I know, but since we've kick-started
> > > development of a new version, I'd like to know what the most
> > > frustrating things with the framework are, even if they're things we
> > > can't fix right away.
- Hard / impossible to organize a large application into smaller /
manageable pieces.
When you have 50 controllers or more in one folder you'll hate
cakephp because it's difficult to locate things. (same problem with
models and views) .
I would like to organize the Model/Views/Controller files into
feature-related, sub-application folders (e.g. newsletter ,
photoeditor, coupon etc.) If 'plugins' is the answer then I hate the
term 'plugin'. My 'newsletter' feature is part of my application, not
a plugin.
- Documentation / User guide should be the focus. People who write the
core should care more about the doc. I would prefer having a better
doc and
more examples to having a newer version of cake.
> - Hard / impossible to organize a large application into smaller /
> manageable pieces.
> When you have 50 controllers or more in one folder you'll hate
> cakephp because it's difficult to locate things. (same problem with
> models and views) .
> I would like to organize the Model/Views/Controller files into
> feature-related, sub-application folders (e.g. newsletter ,
> photoeditor, coupon etc.) If 'plugins' is the answer then I hate the
> term 'plugin'. My 'newsletter' feature is part of my application, not
> a plugin.
> - Documentation / User guide should be the focus. People who write the
> core should care more about the doc. I would prefer having a better
> doc and
> more examples to having a newer version of cake.
> On May 8, 11:05 am, zonium <zon...@gmail.com> wrote:
> > - Hard / impossible to organize a large application into smaller /
> > manageable pieces.
> > When you have 50 controllers or more in one folder you'll hate
> > cakephp because it's difficult to locate things. (same problem with
> > models and views) .
> > I would like to organize the Model/Views/Controller files into
> > feature-related, sub-application folders (e.g. newsletter ,
> > photoeditor, coupon etc.) If 'plugins' is the answer then I hate the
> > term 'plugin'. My 'newsletter' feature is part of my application, not
> > a plugin.
> > - Documentation / User guide should be the focus. People who write the
> > core should care more about the doc. I would prefer having a better
> > doc and
> > more examples to having a newer version of cake.
Habtm implementation:
Model::_deleteLinks($id)
"Cascades model deletes through HABTM join keys."
I just found out reason why some records gets randomly deleted from
habtm:
cake ignores 'condition' filed in habtm assocciation definition.
example:
var $hasAndBelongsToMany = array(
'Tag' =>
array('className' => 'Tag',
'joinTable' => 'content_tags',
'foreignKey' => 'content_id',
'associationForeignKey'=> 'tag_id',
'conditions' => "content_type='News'",
..
Now, cake will use 'condition' to find results,
but ignore when deleting!
So if you have (in this example) tags for Video,Product,Photo..,
by deleting News with id=1,
cake will delete tags for Product id=1, Video id=1.. and so on.
Delete is often followed by redirect to referrer and hard to debug
sql.
This miss-behavior is in cake 1.x, and, as I can see, in 1.2.x.
You can define 'deleteQuery'=> '' in habtm assocciation but why?
@nate should I open ticket for this?
On May 8, 12:29 am, Nate <nate.ab...@gmail.com> wrote:
> Well, maybe hate's a strong word. Let's say, what do you like the
> least? Kind of an odd question, I know, but since we've kick-started
> development of a new version, I'd like to know what the most
> frustrating things with the framework are, even if they're things we
> can't fix right away.
On Fri, May 8, 2009 at 11:46 AM, majna <majna...@gmail.com> wrote:
> Habtm implementation:
> Model::_deleteLinks($id)
> "Cascades model deletes through HABTM join keys."
> I just found out reason why some records gets randomly deleted from
> habtm:
> cake ignores 'condition' filed in habtm assocciation definition.
> example:
> var $hasAndBelongsToMany = array(
> 'Tag' =>
> array('className' => 'Tag',
> 'joinTable' => 'content_tags',
> 'foreignKey' => 'content_id',
> 'associationForeignKey'=> 'tag_id',
> 'conditions' => "content_type='News'",
> ..
> Now, cake will use 'condition' to find results,
> but ignore when deleting!
> So if you have (in this example) tags for Video,Product,Photo..,
> by deleting News with id=1,
> cake will delete tags for Product id=1, Video id=1.. and so on.
> Delete is often followed by redirect to referrer and hard to debug
> sql.
> This miss-behavior is in cake 1.x, and, as I can see, in 1.2.x.
> You can define 'deleteQuery'=> '' in habtm assocciation but why?
> @nate should I open ticket for this?
> On May 8, 12:29 am, Nate <nate.ab...@gmail.com> wrote:
>> Well, maybe hate's a strong word. Let's say, what do you like the
>> least? Kind of an odd question, I know, but since we've kick-started
>> development of a new version, I'd like to know what the most
>> frustrating things with the framework are, even if they're things we
>> can't fix right away.
if one could modify the amount of data that cake fetches during any
operation. For example the action index fetches more result than
needed thereby making the application a bit slower...
and improved tutorials on advanced techniques used in cake like acl..
On May 8, 3:29 am, Nate <nate.ab...@gmail.com> wrote:
> Well, maybe hate's a strong word. Let's say, what do you like the
> least? Kind of an odd question, I know, but since we've kick-started
> development of a new version, I'd like to know what the most
> frustrating things with the framework are, even if they're things we
> can't fix right away.
> Well, maybe hate's a strong word. Let's say, what do you like the
> least? Kind of an odd question, I know, but since we've kick-started
> development of a new version, I'd like to know what the most
> frustrating things with the framework are, even if they're things we
> can't fix right away.
- php4 support++
- upload++
- callbacks on associative queries++
Also:
- saveAll() limitations (currently limited to one level deep)
- more configurability - eg. configure which controller subfolder a
particular controller/model is located in (currently has to search
through all folders in $controllerPaths bootstrap variable, takes
unnecessary time)
- PHP4 support - PHP4 support (I hate it so much) - AjaxHelper (it's existence, without it we will have a lot less traffic on this mailing list) - Too deep nesting of search results in some querys, but I can't figure a way of using arrays and make it not so deep
I hate that it is a powerful framework that can make the tedious work
of developing sites a breeze. Its strict adherence to the tried and
true MVC model is a pain point as well. Why so logical?
I hate the active community involvement and powerful documentation and
API sites. I hate that people expect Cake to do every little thing.
It is a framework! Not a solve everything-all-in-one-cms-portal-file-
manager-blog-forum.
Use the framework to create an upload component, it takes all of 5
minutes!!
On May 8, 8:56 am, "Dennis S. Hennen" <dennis.hen...@gmail.com> wrote:
