On Fri, Feb 6, 2009 at 7:08 AM, Martin <[email protected]> wrote:
>
> 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?)
There are also system vars which are simply variables available system
wide and skinvars which will probably be rename snippets in 3.xx
> All:
> + templated output possible
> + sort and count possible
Templates/Fmt, sort, count, if, and many other options if you are
talking about search/list/find
> + automatic create/store values possible
Yes, depends on which type how it is done. There is a Section Edit
plugin useful for editing sections. Other simpler recipes could be
done as well.
> Info Vars {p::field}:
> + no custom form or action needed, just edit the page, use simple
> pairs "field: value"
But you can also edit by form or function.
> + values accessible with fulltext search command
> - cannot use when "field:" should not show up on the page, like
> "title: My first blogpost"
You can hide it by this, though will show up when editing page text
/*
title: something
*/
> - requires name of page to retrieve value, cannot use a search on a
> group of pages
Not sure what you mean by cannot use a search on a group of pages.
There's almost certainly someway. Just not clear what you mean.
> 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)
Yes, I will probably allow some editing via functions but only of
specifically permitted data fields. This could change depending on
whether or not we want to use the authorization site.auth.read system
I suggested in my last email, which admittedly I''m drawn to.
> Sections {p}#anchor:
> + no custom form or action needed, just edit the page, use simple
> markup
Specific sections can be modified by a form. Also it is possible to
specially construct log functions to add sections to a page. Lot's of
possibilties.
> + values accessible with fulltext search command
> + can use when "field:" should not show up on the page, like "title:
> My first blogpost"
Not sure what you mean here. Normally sections show up (they are just
anchors). But they can be hidden as I did above for the info vars
> - requires name of page to retrieve value, cannot use a search on a
> group of pages
Can use search on full text like anything other page content.
> URL {+p}:
> + can use a search on a group of pages to retrieve data
> + store pages in different folders
This is normally invisible for all purposes, but you can specify
certain folders to speed up a search routine if desired. That is,
irrelevant to page name.
> + 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
But you can create a UTF info page, with UTF equivalents and go back
and forth. Or for that matter, data vars, though info vars might be
faster. This might be an interesting possibility for handling UTF
pages.
Overall I would say the different kinds of data structures are much
more seamless than this chart suggests. I mean you can set up any kind
of pattern for info vars you want, including matching sections as info
vars. You can take any list of items and treat as page names, or vice
versa. You can search an info array and return a list of pages, or
data values or vice versa. You can use a logged page or section as a
list input (converts automatically to csv). In fact you can put csv's
in data or info vars and use them. You can even put search/list/find
functions with other templates pretty much indefinitely. It's not
either or. On most of my more advanced applications I merge back and
forth between the different types all the time. What I've tried to do
is break down any barriers between easy transfer from one type to
another. I think the key is understanding the differences well enough
to be able to pick the one that will do what you need in the fastest
way possible. If you care to describe your project I could possibly
suggest the approach I would use and why...
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
-~----------~----~----~----~------~----~------~--~---
