This sounds great.
I just started to note the different options to store and retrieve
data to make the right decision for a new application. I better wait a
few days before moving on.
But maybe it is good to have the differences in mind before changing
the options or mixing things up.
This is what I have so far.
Info Vars, Data Vars, Sections, URLs/p (did I miss some?)
All:
+ templated output possible
+ sort and count possible
+ automatic create/store values possible
Info Vars {p::field}:
+ no custom form or action needed, just edit the page, use simple
pairs "field: value"
+ values accessible with fulltext search command
- cannot use when "field:" should not show up on the page, like
"title: My first blogpost"
- requires name of page to retrieve value, cannot use a search on a
group of pages
Data Vars {p:field}:
+ can use when "field:" should not show up on the page, like "title:
My first blogpost"
+ stored hidden on a page
+/- values not accessible with fulltext search command
+ can use a search on a group of pages to retrieve data
- editing requires custom form or action (which will change)
Sections {p}#anchor:
+ no custom form or action needed, just edit the page, use simple
markup
+ values accessible with fulltext search command
+ can use when "field:" should not show up on the page, like "title:
My first blogpost"
- requires name of page to retrieve value, cannot use a search on a
group of pages
URL {+p}:
+ can use a search on a group of pages to retrieve data
+ store pages in different folders
+ access different values on position of URL (p1, p2, ...)
- all data shows up in page url (can use some sort of crypting)
- restricted to single expressions (one word or more words
concatenated)
- not UTF-8 compatible
Greetings, Martin
On Feb 6, 3:50 am, The Editor <[email protected]> wrote:
> Just a quick note, that I was able to accomplish the goals I mentioned
> earlier (today?) about changing the under the hood architecture of how
> data is saved and how search/list/find's are processed. It was one of
> those days where everything went right. Beautiful... Here's a short
> update:
>
> 1) There is now a nice system function that allows plugins to easily
> save data. Stripped out of the savedata command and moved into the
> core.
>
> 2) Added a simple [(data )] function which can allow you to set data
> variables in a page automatically. The only security feature I added
> was a setData: title,description,keywords site config value, which
> specifies the only data values you can set this way. You can also
> control the target page. Very simple and nice. But it opens up many
> more possibilities of course as well. I also developed a [(title
> "Some Title")] which works very nicely but will probably shift off to
> a plugin.
>
> 3) Got search/list/find to all run through a single display function
> with separate displayTemplate and displayFmt which makes so much
> better sense. Everything just fell into place. Much clearer, simpler,
> and all the features scattered throughout the various types of
> functions are now available to all three. And they use exactly the
> same syntax. Best of all plugins can tap into the same whole system of
> templating much more easily. Also, the default template is no longer
> hardcoded, but moved to template.default.
>
> One problem though, is I did have to change the parameters list for
> BOLTdisplay, which could affect plugins that use it. We'll have to
> look and see which ones might be affected.
>
> 4) Just for kicks I created a [(display template=whatever)] markup
> which allows you to take any page and run it through any template/fmt.
> I'm not sure all the uses, but it was (now) trivial code, and I think
> there ought to be some easy way to tap into that power. Actually, I
> may cut it out, as I just realized you can do exactly the same thing
> with just [(list {p} template=whatever)]. Well, it was cool while it
> lasted.
>
> 5) My plans are to eliminate library.php and search.php. The functions
> and commands in search will go to commands.php and functions.php. And
> all the system functions in
> library/search/functions/commands/conditions will get dumped into
> engine.php. Markups.php will remain unchanged. The advantages will be
> two less files to read and load. And more logical control of where
> functions are. I want to make it easier to create custom more limited
> replacement scripts (for functions, conditions, commands and even
> markups), and instead of an engine replacement, rather hooks for
> customizing any key functions we want. It's all about a consistent
> paradigm and bringing everything into the plan.
>
> One more thing I plan to do is check for dependencies in the library
> functions. Some may depend on BOLTF functions, but I think fewer and
> fewer... In fact, just checking now the only two I see are
> BOLTFlastmodified in the BOLTsort function and the BOLTindex system
> function which relies on BOLTFindex. That latter one can, and no doubt
> should just be rewritten. Oh, there are also 2 calls to BOLTFsource in
> markups.php--which could perhaps be reworked over to a call to
> BOLTsource. Anyway, I'm going to try to eliminate all dependencies on
> BOLTF functions.
>
> Two more little ideas percolating through my head, now that things are
> streamlined like this. I'm going to set up a hook for custom data
> filters, which will allow you to run your custom functions on data
> input before being saved. And a hook for a customized sort routine,
> like the lastmodified, but open it up to whatever you want. Actually,
> there may already be something like this... I'll have to check.
>
> Ok, I'm done for tonight. Excited about the progress. Will be out of
> town this weekend. I *may* get the new code out before I leave if
> someone is interested in helping test/debug. But more likely it will
> be first thing next week.
>
> Cheers,
> Dan
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
