Does the new info function supports "sort"?
3 views
Skip to first unread message
Linly
Feb 1, 2009, 9:43:07 AM2/1/09
to BoltWire
Hi Dan,
Does the new [(info)] function supports "sort" like the [(search)]
does? Seems not, from my test.
Cheers,
linly
Does the new [(info)] function supports "sort" like the [(search)]
does? Seems not, from my test.
Cheers,
linly
The Editor
Feb 1, 2009, 10:12:53 AM2/1/09
to bolt...@googlegroups.com
Not in the core... Except for count and sum, the default extensions
mostly deals with individual info vars, not systems of them.
But in the infox plugin (Info Extensions) there is a search extension
that taps into the search function, which could possibly get it's
results sorted. There is also a list extension in the core... Though
thinking about it now, that should probably go in the info
extensions... I dunno. We probably could add at least a simple sort
option in the info plugin--perhaps just sort=field or sort=value (only
two options), and maybe order=reverse, and even order=random... Guess
you could just keep adding options. For that matter, we could add a
direct hook into the search function, like the list function. I'm not
sure all the ramifications, but it could be powerful! The hard part
is knowing where to stop with all these things...
Also, anyone try the new help system yet on BoltWire? It's quite cool.
I think I'll be adding a site.help page to make it even easier to tap
into it. Will post more later, after I see what I can do...
Cheers
Dan
mostly deals with individual info vars, not systems of them.
But in the infox plugin (Info Extensions) there is a search extension
that taps into the search function, which could possibly get it's
results sorted. There is also a list extension in the core... Though
thinking about it now, that should probably go in the info
extensions... I dunno. We probably could add at least a simple sort
option in the info plugin--perhaps just sort=field or sort=value (only
two options), and maybe order=reverse, and even order=random... Guess
you could just keep adding options. For that matter, we could add a
direct hook into the search function, like the list function. I'm not
sure all the ramifications, but it could be powerful! The hard part
is knowing where to stop with all these things...
Also, anyone try the new help system yet on BoltWire? It's quite cool.
I think I'll be adding a site.help page to make it even easier to tap
into it. Will post more later, after I see what I can do...
Cheers
Dan
The Editor
Feb 1, 2009, 11:16:20 AM2/1/09
to bolt...@googlegroups.com
Hey, with just a little tweaking I was able to make some big
improvements. The next release has a core "report" extension which
essentially taps into the search engine allowing conditions, sorting,
reverse order, and full fmt/template output. This is cool. And the
code is slim... I deleted the list extension in the core as this is
far superior.
I setup a demo page to show off the new tricks. Check here:
http://www.boltwire.com/index.php?p=test.info.report
Cheers,
Dan
P.S. Also, Linly & Shawn did you notice I added a more limited <html>
option in the last release. It's still currently called <nolines> but
it only allows the allowed tags in BOLTattrs['html'] and no other. So
for simple html it's ok. But for full html, you want something like
the other option I suggested. Just it's very dangerous.
improvements. The next release has a core "report" extension which
essentially taps into the search engine allowing conditions, sorting,
reverse order, and full fmt/template output. This is cool. And the
code is slim... I deleted the list extension in the core as this is
far superior.
I setup a demo page to show off the new tricks. Check here:
http://www.boltwire.com/index.php?p=test.info.report
Cheers,
Dan
P.S. Also, Linly & Shawn did you notice I added a more limited <html>
option in the last release. It's still currently called <nolines> but
it only allows the allowed tags in BOLTattrs['html'] and no other. So
for simple html it's ok. But for full html, you want something like
the other option I suggested. Just it's very dangerous.
Linly
Feb 2, 2009, 2:06:02 AM2/2/09
to BoltWire
Wow, wonderful!
This solved any kind of "most read" "most rate" ... request.
This solved any kind of "most read" "most rate" ... request.
The Editor
Feb 2, 2009, 4:32:42 AM2/2/09
to bolt...@googlegroups.com
On Mon, Feb 2, 2009 at 2:06 AM, Linly <linl...@gmail.com> wrote:
>
> Wow, wonderful!
>
> This solved any kind of "most read" "most rate" ... request.
>
> Wow, wonderful!
>
> This solved any kind of "most read" "most rate" ... request.
Hey, you are right... Good point! Can also use for posts with recent
comments or whatever. It is also very fast.
Cheers
Dan
Linly
Feb 2, 2009, 8:22:50 AM2/2/09
to BoltWire
> Hey, you are right... Good point! Can also use for posts with recent
> comments or whatever. It is also very fast.
Fast, really fast. Comparing to use [(search)], I use [(info)] to find
> comments or whatever. It is also very fast.
50 matching pages cost only one third of time to display the result.
linly
Linly
Feb 2, 2009, 10:57:21 AM2/2/09
to BoltWire
Btw, Is it possible to use "sort=lastmodified" in [(info)]?
Cheers,
linly
Cheers,
linly
The Editor
Feb 2, 2009, 11:59:48 AM2/2/09
to bolt...@googlegroups.com
If you are doing [(info report sort=lastmodified...)], yes, because it
taps into the search function which will sort things---assuming the
info is a list of page names for the info fields. (ie, the fields must
exist).
Otherwise no. Because there is no lastmodified information in the info
page itself. It's all just fields and values... That's why it's so
fast. It doesn't have to (normally) scan any pages or use a big index.
Cheers,
Dan
P.S. I've been doing a lot of advanced stuff on my site involving data
mining (where I create info pages of certain data dynamically) and
have toyed a bit with the idea of being able to store more than one
data field in a info value, like:
some.page: data1#data2#data3
We really only need to settle on some kind of data delimiter (a
default, configurable, obviously) and some way to extract the
appropriate part. Maybe {info::some.page#0} or something. I'm open to
suggestions. This could take the info vars up a whole nother notch,
making it possible to do all kinds of new things...
taps into the search function which will sort things---assuming the
info is a list of page names for the info fields. (ie, the fields must
exist).
Otherwise no. Because there is no lastmodified information in the info
page itself. It's all just fields and values... That's why it's so
fast. It doesn't have to (normally) scan any pages or use a big index.
Cheers,
Dan
P.S. I've been doing a lot of advanced stuff on my site involving data
mining (where I create info pages of certain data dynamically) and
have toyed a bit with the idea of being able to store more than one
data field in a info value, like:
some.page: data1#data2#data3
We really only need to settle on some kind of data delimiter (a
default, configurable, obviously) and some way to extract the
appropriate part. Maybe {info::some.page#0} or something. I'm open to
suggestions. This could take the info vars up a whole nother notch,
making it possible to do all kinds of new things...
Linly
Feb 2, 2009, 8:58:06 PM2/2/09
to BoltWire
I overlook about the difference between "info tags" and "info report".
By using "info report", I can do the sort=lastmodified easily.
While talking about info function, I prefer using the info.* files one
purpose per file, "info.count" records the count data, "info.rate"
records the rate data, "info.tags" records the tag data...
I haven't test yet, but if BoltWire could combine those, say, the most
rated page in some tag value, that would be great.
Cheers,
linly
On 2月3日, 上午12時59分, The Editor <edi...@fast.st> wrote:
> If you are doing [(info report sort=lastmodified...)], yes, because it
> taps into the search function which will sort things---assuming the
> info is a list of page names for the info fields. (ie, the fields must
> exist).
>
> Otherwise no. Because there is no lastmodified information in the info
> page itself. It's all just fields and values... That's why it's so
> fast. It doesn't have to (normally) scan any pages or use a big index.
>
> Cheers,
> Dan
>
> P.S. I've been doing a lot of advanced stuff on my site involving data
> mining (where I create info pages of certain data dynamically) and
> have toyed a bit with the idea of being able to store more than one
> data field in a info value, like:
>
> some.page: data1#data2#data3
>
> We really only need to settle on some kind of data delimiter (a
> default, configurable, obviously) and some way to extract the
> appropriate part. Maybe {info::some.page#0} or something. I'm open to
> suggestions. This could take the info vars up a whole nother notch,
> making it possible to do all kinds of new things...
>
By using "info report", I can do the sort=lastmodified easily.
While talking about info function, I prefer using the info.* files one
purpose per file, "info.count" records the count data, "info.rate"
records the rate data, "info.tags" records the tag data...
I haven't test yet, but if BoltWire could combine those, say, the most
rated page in some tag value, that would be great.
Cheers,
linly
On 2月3日, 上午12時59分, The Editor <edi...@fast.st> wrote:
> If you are doing [(info report sort=lastmodified...)], yes, because it
> taps into the search function which will sort things---assuming the
> info is a list of page names for the info fields. (ie, the fields must
> exist).
>
> Otherwise no. Because there is no lastmodified information in the info
> page itself. It's all just fields and values... That's why it's so
> fast. It doesn't have to (normally) scan any pages or use a big index.
>
> Cheers,
> Dan
>
> P.S. I've been doing a lot of advanced stuff on my site involving data
> mining (where I create info pages of certain data dynamically) and
> have toyed a bit with the idea of being able to store more than one
> data field in a info value, like:
>
> some.page: data1#data2#data3
>
> We really only need to settle on some kind of data delimiter (a
> default, configurable, obviously) and some way to extract the
> appropriate part. Maybe {info::some.page#0} or something. I'm open to
> suggestions. This could take the info vars up a whole nother notch,
> making it possible to do all kinds of new things...
>
The Editor
Feb 9, 2009, 8:35:31 PM2/9/09
to bolt...@googlegroups.com
On Mon, Feb 2, 2009 at 8:58 PM, Linly <linl...@gmail.com> wrote:
>
> I overlook about the difference between "info tags" and "info report".
> By using "info report", I can do the sort=lastmodified easily.
>
> While talking about info function, I prefer using the info.* files one
> purpose per file, "info.count" records the count data, "info.rate"
> records the rate data, "info.tags" records the tag data...
>
> I haven't test yet, but if BoltWire could combine those, say, the most
> rated page in some tag value, that would be great.
>
> I overlook about the difference between "info tags" and "info report".
> By using "info report", I can do the sort=lastmodified easily.
>
> While talking about info function, I prefer using the info.* files one
> purpose per file, "info.count" records the count data, "info.rate"
> records the rate data, "info.tags" records the tag data...
>
> I haven't test yet, but if BoltWire could combine those, say, the most
> rated page in some tag value, that would be great.
You should be able to do this, by nesting the functions. The first one
returns a simple csv list of all the pages in a certain tag, then
those values are sorted by their count value. Something like [(info
report {(info report ...)} )]
I'm too tired to try the thing, but don't see why it couldn't be done...
Cheers,
Dan
Reply all
Reply to author
Forward
0 new messages