Damon, Sorry for this late answer. I was busy with a job and completely forgot to reply.
> You should have led with this in your initial inquiry. :) The problem with > asking, "how do I do X" instead of "I'm trying to do X, what is the best way" > is that sometimes your question gets answered without actually giving the > RIGHT answer. I know and you are definitely right. I was reinventing the wheel, but it wasn't a problem by itself. I just got an unexpected Rivet behavior so I was wondering whether it was right, or maybe a bug. Discussions about what I was trying to get came out after, and I got realy precious hints. > In this case, Tcl already does what you want. It's called auto_load. I remember I've seen it before, but didn't come to mind because I never used it. I'll give it a look, because seems to fit well. > All that being said, it may be a better idea to be explicit. [...] I generally agree, but web developers I personally know are very lazy. Again, I'm exploring a few options now, I haven't really decided how the framework will be. >[...] That said, I will offer a few notes before you tilt at this windmill. 0-] Thank you, I appreciate it! > 1. Don't worry about objects. Everyone loves OOP, that's cool, but you > don't need it here. At least not a parent, singleton object for each > request. You already have that, it's called the ::request namespace. Rivet > builds it, executes in it, and destroys it with every request. Creating an > object on top of that just to run your framework is overkill. I completely agree! I'm putting singleton data into ::request and its children namespaces. Objects become a viable option as soon as you want an MVC pattern: basic models, controllers and views can then become classes which the framework provides, and user code inherits from them for specific web app stuff. So, for me, OO is welcome but only in specific areas, where it's really useful. > 2. Like you've already decided, keep the bits separate. I have the main > framework, a DB package and a UI package (for forms and other bits of web UI > sundry) all in packages that you can choose to use or not choose to use. > Cuts way down on load times. Yes, I want to reduce load times as much as I can. The basic framework job is to parse the request, find what user code must be executed, and run it. That's all, as much as CI, Fuel, and others do. > 3. Initialize your framework in the global namespace one time using the > package mechanism, then you don't have to incur that cost with each request. > ESPECIALLY in production code. I built a debug variable in which says that > I'm in a "dev" instance of the framework, and in dev mode the entire > framework is reloaded with each request. This is for me when I'm developing > the framework and other bits. I want to reload each time to make sure my > changes are in. I'm following a similar path, but with a big difference: I load code into the global namespace only if the SeparateVirtualInterps is true (and I always put data into ::request). The reason is simple: if, let's suppose, someone starts a hosting company offering Rivet access, then unless SeparateVirtualInterps is true the global namespace becomes shared among different virtual hosts belonging to different users (as soon as requests go to the same Apache child, I know). Then, I *should not* put code into the global namespace because it could interfere with other users code. One of the premises to my work on this framework, is to make it ready for those configurations, so I must go the safer path. Thank you again, Damon, for sharing your experiences, I really appreciate it :) Bye, Marco --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
