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
-~----------~----~----~----~------~----~------~--~---
