Well, again, it's not a matter of can or can't, the thing is, there's no why... even wanting a full featured view, with whole lots of data of all sorts of associations and purposes, what you have to keep in mind is, "why?" : where does it fits in your app design? and if you ever planned it or just come with a quick answer then you can jump to "how?". Cake is just fine for every kind of app with any amount of data to be pulled out and in the database. Why bother about something that you actually not even figured out? If you want a "profile like" interface, where the user can have access to lots of lists and tables of lessons, events, homeworks, available jobs, or anything else, you should ask, does it has to be loaded all up to the bottom at once? because all-in-one-single-page web apps don't do that, you have to rely on JS/JSON/XML/AJAX to fill some tasks, or else you will end up in a bloody mess with a "could-be-so- light" app turned into a fat old lady that tries to display more than 300 sources of data at once. You have to keep in mind that dynamic apps rely in much more concepts and methods than just in the strong framework it was built on top of, and it's not a matter of knowing framework's features - I could point lots of them wich you are missing (pagination, cache, alt type content delivery...) - it's about having a well planned goal.
Must read: http://www.littlehart.net/atthekeyboard/2007/01/02/just-build-it-damnit/ So my tip is: Abuse of JS if you want dynamicity, and pages bundled with lots of data, try to keep things as simple as possible, remember that a view for a "index" action should be an "index" of data, anything extra to show becomes a VIEW feature. On 24 set, 13:47, Mike <[EMAIL PROTECTED]> wrote: > Thanks for the response - the idea of 'minimizing data that PHP > processes' as a design pattern for PHP web apps is an insight that I > had totally missed, and appreciate your pointing it out. It also > helps to explain why there isn't a whole lot on the internet about > perf tuning/profiling CakePHP apps :) > > I think I may have mis-architected my program. What I wanted to do is > have a student visit a single page, where everything is available. > Using the HTML fieldsets as visual panels, I wanted to have a panel > that would let the student upload their homework (which requires a > list of homeworks for the current course), another panel with a set of > links to work that they'd previously uploaded (so they can see that it > was submitted, and so that they can re-download it later), etc, etc. > My hope was that I could ask Cake to get the user information for the > current student, set recursive = 3, and then have Cake prune away any > data that didn't pertain to the current student. After which, it's > quick-and-easy to render all the stuff that I'm looking for :) > > I think that because of the way I've got my tables set up, recursive=3 > and doing a find on the user account didn't quite go deep enough (I'm > not quite sure if this is a bug in PHP, or my code, or what)(almost > certainly my code, but I haven't debugged it enough to get beyond the > initial stage of "This _should_ work" :) ) > > So I'm worried about scalability not because of trying to display 800 > rows at once, but because I think that I'm mis-using Cake to get too > much info & pruning it back once it's all in memory. > > Actually, if you don't mind - what sort of capacity should Cake/PHP > have for pulling stuff into memory? > I assume that anything less than 100 rows of data should be fine - > what about 200? 300? 500? I don't know if anyone's done any sort of > measurements about "CPU X, with memory Y GB, Cake can draw Z records > into memory in A milliseconds", but it would be fascinating to see :) > > Thanks again for the quick, really helpful response! > (And, for what it's worth, I'm loving Cake right back! :) ) > --Mike > > On Sep 24, 8:17 am, Rafael Bandeira aka rafaelbandeira3 > > <[EMAIL PROTECTED]> wrote: > > Mike, I think it's not "how much data is Cake intended to deal with" > > is how much data your app is intended to deal with, > > thousands of records is not something that should be dealed by php, > > the database does it much faster and safer. > > Having lots of data in database doesn't mean you have to deal with > > them always - I would say ever - because you would rarely want users > > stumbling their heads on to a 800+ rows report, I would say that > > using a 30+ limit in a report/index is already annoying. > > Now how do you intend to support thousands of records include in the > > app database if not with a file upload? there's no way to make a user > > fill more than three forms at once... And as the database can handle > > files, al you have to do is parse the file if needed. > > > Cake loves you and will do lots of things for you, but it's still php > > and still uses memory, relies on cpu process and all this stuff. > > > rafaelbandeira3http://rafaelbandeira3.wordpress.com > > > On 24 set, 03:25, Mike <[EMAIL PROTECTED]> wrote: > > > > Thanks for the tip! In the previous, non-Cake version of the app, I > > > did that exactly, so it shouldn't be too too tough to get it up and > > > running again. I was kinda avoiding SQL b/c it seemed like "the Cake > > > way" should be to push it through the Cake layer & let CakePHP make it > > > automagically happen. Hearing that raw SQL is actually the right way > > > is actually really helpful :) > > > > If you don't mind my asking a couple more questions - how does one > > > know where the boundary should be? I mean, aside from exceeding > > > max_execution time and/or running out of memory - how would I know > > > where to draw the boundary between 'small enough for Cake' vs. 'needs > > > raw SQL' when designing my app? (And what does a normal app do if a > > > user happens to show up with an unexpectedly huge data set?) > > > > Also, what sort of data sets is Cake intended to support? I'm writing > > > the app to support my teaching, so having 30 people in a class, with > > > 10-20 homeworks/exercise sets to hand in (each of which might have 2-3 > > > versions stored), so it's conceivable that Cake might auto-magically > > > pull 600-1,200 records (even if fairly few / none of them are used in > > > any given view). One of the things I really liked about Cake was that > > > I could set recursive = 2 (or 3), and have it magically pull > > > everything I needed out of the DB (in my raw PHP app, I figured it was > > > time to look at a framework when I started to move towards an OOP-y > > > iterator approach for dealing with all my lists of data :) ) > > > > Thanks again for the quick reply - I appreciate the 'ok' from someone > > > who knows more about this than I do! :) > > > --Mike- Hide quoted text - > > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
