I've decide on trying to tackle 2 system changes to BoltWire that
should not change behavior of existing sites, but 1) simplify code, 2)
increase options, and 3) make it much easier to develop advanced
plugins. Changes like these of course always have the potential of
introducing bugs however...
Change 1: Currently, we have two different access points to the
templating engine: the search function and the list function (also
commands...). Both generate an array of "hits" by different
mechanisms, then sends that array and the args either to a fmt or
template handling routine by various and sometimes convoluted means.
To give both search & list the robustness I've wanted, I've also had
to duplicate a lot of code. And use several nifty little tricks to
wire all the strands together. I'm thinking we should have a single
function that takes the array and args, does all the conditions and
sorting, etc, and outputs the results. In fact, probably we should be
able to tap into this function directly via [(display template <opt.
page=base.page> )]. I think it will work much better to have
everything run through a single stream... And both list and search
will get new features for free. In less code. I'll work on this some
more and let you know what comes of it.
Change 2: Currently the savedata commands has lagged behind it's
sister, the info var capabilities. In particular, there is no simple
system function that allows you to directly modify a data variable
without going through the command, so most plugins have to build their
own subroutines. Inefficient. So I plan to strip out parts of the
savedata function, make it into a core system function, and then have
savedata simply tap into that code. Making it a system function, means
it is trivial to do savedata kinds of plugins. You could even do a
savedata markup function, though there are some security issues
involved here. (Currently data can only be changed via forms or
plugins, but we could have a site.auth.data authorization page to
control write access just like with info vars and then open things up
to functions. Most likely it would be highly protected except when
done through forms.) One example of a use would be a [(title "Some
Page Title")] options you could embed in a page. Or even: [(title
"{::title}")] in a group header/footer to automatically take the title
from the info var on the page. Cool. Also metatags! We would have to
rename the current site.auth.data page to something else, like
site.auth.read (for reading data, and perhaps even controlling system
and info var access by systemfield: @users and :datafield: @users and
::infofield: @users. Wow!).
Well, just thinking out loud. For those of you who have taken some
time to look under the hood at the actual BoltWire code, and who have
programming experience, I'm always open to suggestions for other ways
to maximize the internal architecture of BoltWire. It's quite modular
already, and it's getting better all the time, but there's always room
for improvement. For me BoltWire is not just a tool, but art. It's not
only about what works, but about what is ideal... If we keep striving
for excellence, we'll end up with it.
Thanks for listening to me ramble out loud...
Cheers,
Dan
P.S Here's another thought... What about eliminating the search.php
script and divvy out all the code to the appropriate functions
(library, functions, commands). And while we are at it, why not just
dump all the library stuff into the engine. That would bring us down
to 5 core scripts. Simpler, and easier to find stuff maybe... Well,
I'm getting excited about a 3.xx release in case you can't tell.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"BoltWire" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/boltwire?hl=en
-~----------~----~----~----~------~----~------~--~---
