> wouldn't the good old 'package require' command do the work?
I think you are right, the "package require" could work well and
easily, especially
for framework provided stuff.
I started with some class autoloading code, as seen in PHP frameworks, then I
thought namespaces would be better suited for some parts and started with
autoloading them, then I immediately found the strange behavior and reported it.
>> Of course, there are chances the user really called a non existing procedure,
>> or asked for an unknown subsystem, in which case the original ::unknown
>> must be executed.
>
> I'm not sure I get the picture
I wasn't clear, I apologize. Let me try to explain again :-)
I want to make web programmer's life easy. I want she just *uses* what she
needs, without caring about *loading* it. Of course, this is the ideal case, and
I'm trying to achieve that stepwise.
Let's assume there are db facilities in a ::Db namespace. The framework itself
doesn't need them to work, so it doesn't load them in order to save time and
memory.
Soon or later, after the framework is ready, a user code will be run depending
on the request. Let's suppose that code *needs* the db stuff, so there could be
a line such
Db::query "sql query"
Here, Db::query is not known, the ::unknown proc will be called, and there magic
happens: the framework-provided ::unknown finds that Db is a known subsystem,
it finds the right file containing it, it sources that file, making
the Db namespace
available; then it could call some initializing proc, such as
::Db::init, and finally,
it retries the Db::query call.
But if the user wrote a *wrong* command, maybe because she mispelled it,
Db::queralsjkfh "sql query"
after Db has been loaded, the "queralsjkfh" proc wouldn't be found inside it, so
the original ::unknown proc (which I renamed to ::_unknown) must be called to
handle the error.
The same holds if the user wrote a *wrong* namespace
Tb::query "sql query"
In this case, the auto loading facility can't find a file containing
the Tb submodule,
so it must raise an error.
The autoloading facility should be as transparent to the user as it
can. It should
work either when (for example) Tb is part of the framework, or is part
of the web
application itself. I'd like to let the user simply write
Tb::query "sql query"
and have the right code executed or an error raised.
> Error messages are unlikely to change and I understand you are trying to infer
> their meaning from the message but I think it's an approach with many pitfalls
> and you have just found one of them. I think you should draw on the many
> introspection capabilities of Tcl in order to have a better insight in what's
> going on in you application
Once again, I wasn't clear enough, I apologize. I'm *not* trying to
infer the meaning
of an error from the message itself. I just found that the error message changes
when I rename ::unknown to ::_unknown and call the latter from the former to
simulate a direct call to the original ::unknown proc, and this is a
deviation from
the standard Tcl behavior.
What does it mean to me? Probably nothing! A user of the framework will just see
a dirtier error message when calling a non-existing proc, and my hope
to completely
hide the autoloader magic fails.
> So, why don't you prepare a few web pages on you work?
> You may open a section on the wiki http://wiki.apache.org/tcl/Rivet
> and throw in your ideas.
Basically, because I still don't know where I want to get and how to get there.
All the code I wrote is just for exploring these paths, but I don't have a clear
and sound architecture in mind, as you surely understood.
When I'll feel comfortable, I'll surely prepare some pages about it and a public
repository on github or bitbucket for those who want to give a look.
> I probably should do something like I've just suggested to you and open up my
> work
> for everyone to criticize it
It would be very nice, expecially to see other implementations in the
area of security
and user input handling.
> My hope is simple, that we can end up having something flexible and light
> enough
> to be easily stretched to be reused in the many cases where one needs to
> create a web interface to some application.
Definitely agree, it is a strong requirement for making Tcl compete with other
solutions and increase its usage base.
Marco
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
