Wow Wow Wow. So many interesting improvements. I'm esp waiting to use
the change of pagedata plugin moving into core. In this way it almost
can satisfy any data, info request. Great.
Btw, is it possible to set multi-value to a data field? Say, for the
tag usage like:
Category: History,ChildrenBooks,PictureBook ...
I know there is a tags plugin already but it can not set utf-8
values. :( So I have to look for other solution to set utf-8 tags. And
for this purpose the datasearch should be capable to find one or two
or all of the values in a multi-value data field.
Sorry this must be no use to English users, but I think even European
users would like.
Cheers,
linly
On 8月26日, 上午12時43分, "The Editor" <[EMAIL PROTECTED]> wrote:
> It was good to see the discussion on BoltWire while away, and see
> others on the mail list providing good answers and information. Very
> encouraging! It may take me a day or two to catch up with the emails
> that still need responses but I'll get to them as I'm able.
>
> This email is just an update on a couple of the projects I was able to
> do while away. Had some great inspiration, and was able to hammer out
> some cool new code. Most were just trivial changes. Like connecting
> wires between already existing batteries and engines. (Why they call
> it BoltWire!)
>
> I did however do a LOT of work on the pagedata plugin and will likely
> release it soon as a new plugin with a new name--or more likely move
> it into the core. More on that below. Anyway, here are changes coming
> in the next release.
>
> 1. Can now use the core mail function to send messages to members. If
> the to or from field is set to a recognized member id, and that
> profile has an email address, BoltWire will automatically replace the
> member id with the email address. This makes very nice mail
> functions/forms possible, like the following:
>
> [form]
> [select to]
> [option bob]Bob
> [option joe]Joe
> [option sue]Sue
> [option tina]Tina
> [select]
> [session from Caveman]
> ...
> [session mail parameters]
> [submit]
> [form]
>
> 2. New source command. Taps into the existing source command and can
> take most any parameter it can. That is, it can get page content,
> anchors, data vars and text vars, all easily. This is especially
> powerful because it is processed AFTER form submission, meaning you
> can use it to retrieve anything from anywhere based on user input. To
> give an idea of the scope of this powerful addition, study the
> following form:
>
> [form]
> [select mypage]
> [(search group=login fmt="[option {+p}] {+p}")]
> [select]
> [session source "{=mypage}:email"]
> [session warn "{=source}"]
> [submit]
> [form]
>
> 3. Fixed the problem with the : in the link parameter xml:lang, by a
> custom hack which accepts xmllang and inserts the colon automatically
> Not pretty, but simple enough and it works. Trying to get BoltWire to
> accept : in the field name would have been much more problematic, if I
> could have done it at all. Hope this
>
> ----
>
> Now as for the pagedata plugin, I've completely reworked it and am
> inclined to rename it either data or info and move it to core. Here
> are the specs:
>
> * The data page is now defined by "page" rather than data. Will
> probably change default page from site.public.data.counter to
> data.counter or info.counter. Depending on the name, info or data will
> be a common hierarchy like log or group.
> * The field name is now called field rather than page. Value is still
> called value
> * Count and sum functions work as before.
> * By default it functions as a page counter, also if you set to [(data
> counter)]. Note the "er" on the end.
> * Reworked the logic a bit so you could do [(data field=some.page)]
> and counting takes place by default
> * If sum or count is specified, but no field, values are saved to
> sum.$args['sum'] and count.$args['count'].
> * Can now create easy plugin BOLTdata function, like BOLTdataSearch or
> BOLTdataWhatever. To trigger call [(data Whatever Parameters...)] etc.
> * Clean, Report, and Archive functions all reworked to separate
> BOLTdata functions. Each polished and cleaned up. Will be made
> available as a separate plugin, while rest of data goes to core.
> * I added a BOLTdataMine function like: [(data mine field=email
> page=data.member.email group=login)] and an optional var=text to
> datamine textvars. The function scans the designated pages, generates
> a data file, and saves it to the specified location. This could be
> used with cron to update data files periodically, and then the data
> function could be run off these pages for really fast results. Quite
> powerful stuff.
> * Added a very cool BOLTdataSearch function which allows you to search
> for specific data values on a specified page and sends it to
> BoltWire's search function for display (templates, fmt, sort, etc...).
> So you could for example display the email of every member who lived
> in a certain state, very easy and fast. Something like: [(data search
> value=oklahoma fmt="login.{+p}:email")]. It would be nice to add some
> kind of capability to match things that are close, or within a range,
> etc, to give it more power. But these can be developed as we need to,
> as all the plugin function will be, well, plugins! Our core won't
> need to change.
>
> Actually, the hardest part was/is trying to decide what to call it.
> Pagedata is no longer really appropriate, because it's any kind of
> data--not just page hits and the like. I like "data" because it's
> short and we can setup a whole data hierarchy for all kinds of things.
> But generally in BoltWire, data refers to hidden page data, not text
> vars (data in the page text--which is what this function handles). So
> a better name might be textdata or textvars. (We already have a
> plugin by the latter name).
>
> Thinking about it more, I'm inclined to call it "info", and start
> referring to text vars as page info. Clearly separating info and data
> will be helpful. (Just a bit of relearning on our part.) And info is
> nice and short and sweet. Anyway, it is a powerful and fast approach
> to handling a lot of info, that dramatically expands BoltWire's
> capabilities beyond how it otherwise handles data. I'm open to
> feedback on this proposal before releasing it.
>
> 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
-~----------~----~----~----~------~----~------~--~---
