Thanks Dan. Good plan; I like it.
On Thursday, 11 February 2016 20:28:06 UTC+2, Dan wrote:
>
> Jan,
>
> The {dir} can be achieved by adding the following elseif line to the
> BOLTpageShow function in library.php ~1420
>
> if (isset($BOLTvar['action']) && ! inlist($BOLTvar['action'],
> 'print,view')) $actionPage = BOLTgetlink($BOLTvar['action'], 'action');
> elseif (BOLTfolders($pageLink) != $pageLink) $BOLTvar['dir'] =
> 'pages/' . substr(BOLTfolders($pageLink), 0, strlen($pageLink));
>
> It could also be done by something similar in a config.php file.
>
> Not sure it is worth including in the core though. It would have trivial
> impact on performance, and it does seem to work for the intended purpose. I
> can see a lot of uses as I'm constantly doing things like
>
> [(search group=forum dir=pages/forum...)] and could just do [(search
> group=forum dir={dir}...)]
>
>
> Tiffany,
>
> I like what you did with the form. I think we could add it and the map
> page to the XPack, and maybe delete action.zones from the core. Yours
> perhaps could be a merger of the zones and data action, and if so we could
> make the info vars editable fields like the data action. I'm thinking a one
> stop action page for setting everything on a page...
>
> As for the map page, indexing is a good option for speedy generation of a
> kids list. But the big thing is it needs to be automatic. Most of my
> indexes are specialized for specific sections. So it would be difficult or
> impossible to have an action that works for any page. If we use the {dir}
> approach it works perfectly if there are no site folders specified and
> since most of my folders include top level pages on down like forum,
> forum.area, forum.area.timestamp, it should work for all of those. Not 100%
> but a strong 99% I'd say.
>
> Kind of a cool development...
>
> Cheers,
> Dan
>
> On Thu, Feb 11, 2016 at 11:58 AM The Editor <fast...@gmail.com
> <javascript:>> wrote:
>
>> Yes the problem remains because BoltWire has to scan all possible pages
>> and then run conditionals, types, includes/excludes, and sorting before it
>> can trim down to the specified count of pages. It does default to 50 hits
>> on the display, but it still has to scan everything unless you specify the
>> directory.
>>
>> Cheers,
>> Dan
>>
>> On Thu, Feb 11, 2016 at 8:02 AM TMurNGon <tmur...@gmail.com <javascript:>>
>> wrote:
>>
>>> Yip, action.map is probably the best name.
>>>
>>> I now understand the problem with a large search result. Does the
>>> problem remain if you limit the number of items returned to the *top*
>>> few records? In other words does the query terminate once the required
>>> number of items have been found or does it keep going regardless? If that
>>> solves the problem will the built-in configurable limiter not solve the
>>> issue - simply don't allow an unlimited return. For the typical use case
>>> it doesn't really make sense to return hundreds of records anyway. I see
>>> it more as a convenience action.
>>>
>>> I most definitely like the {dir} variable though. It will make life a
>>> lot easier.
>>>
>>> I agree that the best change to zones will be simply adding 'title' and
>>> 'breadcrumb' - else it may become too overloaded.
>>>
>>>
>>>
>>> On Thursday, 11 February 2016 15:46:48 UTC+2, Dan wrote:
>>>
>>>> I see. Sounds like a great idea. Since you are aiming this at general
>>>> users, calling it action.map makes more sense to me than action.toc.
>>>>
>>>> Not sure I will add it to the core, but possibly a simplified version
>>>> to go in the XPack--mostly because of the directory problem on large
>>>> sites.
>>>> And it is definitely easy to create for those who want it. On the other
>>>> hand, it doesn't hurt to have it! Still like the idea of having a {dir}
>>>> variable.
>>>>
>>>> And given this, the only questions remaining are 1) should action.zones
>>>> be renamed and 2) what additional features should be given to it?
>>>>
>>>> I'm inclined to stick with zones to minimize unnecessary change and if
>>>> anything just add Title & Breadcrumb... to the top of that action. We can
>>>> keep the data stuff in that action. Anything else I'm missing?
>>>>
>>>> Cheers,
>>>> Dan
>>>>
>>>> PS. The performance problem is not the number of pages displayed, it is
>>>> actually the scanning itself. So using the count parameter doesn't really
>>>> help. You have to limit your scans to specific directories on really large
>>>> sites for optimum performance. Or switch to a database on the back end.
>>>>
>>>
>>>>
>>>> On Thu, Feb 11, 2016 at 7:34 AM TMurNGon <tmur...@gmail.com> wrote:
>>>>
>>>>> I quite like all the action name suggestions. if I had to choose I'd
>>>>> say 'info' as it is the most descriptive while remaining short.
>>>>>
>>>>> My initial attempt at this was actually as an expansion of the zones
>>>>> action. The reason that I moved it out again is that I don't allow
>>>>> direct
>>>>> access to the zones action or the data action to all users (in fact very
>>>>> few), but I do automatically forward to the tree/info action on my higher
>>>>> level pages that have the primary role of acting as a kind of table of
>>>>> contents for the pages below. For the same reason I am still a little
>>>>> unsure on whether to display {data} on this page. To non-technical users
>>>>> it is really just meant as a means of orienting the page in the site
>>>>> (almost like a partial site map - 'you are here').
>>>>>
>>>>> Perhaps the ideal solution would be to have a simpler action (called
>>>>> 'map' or 'toc'??) for more general use and then add all of the other good
>>>>> stuff into the 'zones' action ('info' action??) so that you can get a
>>>>> complete rundown on the page if you are a technical user??
>>>>>
>>>>> As for very large sites (or any large search result set), perhaps
>>>>> there is a way of implementing 'paging' functionality of some sort? It
>>>>> would be useful in many areas and looking at the 'count' parameter in the
>>>>> 'search' function I think that Boltwire is well on its way to enabling
>>>>> paging anyway.
>>>>>
>>>>> Just my two cents...
>>>>>
>>>>>
>>>>>
>>>>> On Thursday, 11 February 2016 15:02:53 UTC+2, Dan wrote:
>>>>>
>>>>>> Nice. A couple suggestions...
>>>>>>
>>>>>> Maybe a different name might be better to avoid confusing it with the
>>>>>> admin module called tree. That is if we end up doing something like this
>>>>>> in
>>>>>> the core/expansion pack. How about: action=page, action=pageinfo,
>>>>>> action=info... Just thinking out loud.
>>>>>>
>>>>>> What about combining this with the zones action? That way you have
>>>>>> all the zone information on the page as well. I have a lot of complex
>>>>>> pages
>>>>>> and find that action quite helpful. On that action there's also
>>>>>> the [(system {p})] function which would be quite useful here as well.
>>>>>>
>>>>>> I assume for the subpages you use a search function? This is handy,
>>>>>> but on a large site might be a problem if you don't specify the
>>>>>> directory
>>>>>> (My site is pushing 100,000 pages). One solution might be to create a
>>>>>> page
>>>>>> variable like {dir} then you can set that in the search function. But
>>>>>> then
>>>>>> on the other hand, there's no guarantee all the child pages will be in
>>>>>> the
>>>>>> same directory. This part is problematic.
>>>>>>
>>>>>> The associated list of data variables could come with a link to the
>>>>>> data action so you can edit the data actions.
>>>>>>
>>>>>> Anyway, just some initial thoughts. What do you think?
>>>>>>
>>>>>> Cheers,
>>>>>> Dan
>>>>>>
>>>>>> On Thu, Feb 11, 2016 at 1:12 AM TMurNGon <tmur...@gmail.com> wrote:
>>>>>>
>>>>> Hi Dan,
>>>>>>>
>>>>>>>
>>>>>>> I just thought I'd mention a suggestion for a new action that may be
>>>>>>> useful:
>>>>>>>
>>>>>>> I just call the action 'tree' (but some other name like 'info' may
>>>>>>> be more appropriate)
>>>>>>> Basically it is an informational view of {p} which shows:
>>>>>>>
>>>>>>> =====================================================
>>>>>>> [(breadcrumb)]
>>>>>>> {title}
>>>>>>> ----
>>>>>>>
>>>>>>> Page Name: {p}
>>>>>>>
>>>>>>> Sub Pages:
>>>>>>> /*A table of contents of sub pages using template like:*/ [(toc {+p}
>>>>>>> offset={p0})][[{+p}|{+title}]]
>>>>>>>
>>>>>>> Associated Data Variables:
>>>>>>> {data}
>>>>>>>
>>>>>>> =====================================================
>>>>>>>
>>>>>>> This provides:
>>>>>>> - a quick way of determining the place of a page in the hierarchy
>>>>>>> (via the breadcrumb)
>>>>>>> - an easy view of and access to child pages (via the toc)
>>>>>>> - some insight into data variables available on the page
>>>>>>>
>>>>>>> I use this quite a lot and thought it may be of use to others as
>>>>>>> well.
>>>>>>>
>>>>>>> Thanks.
>>>>>>> Jan
>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "BoltWire" group.
>>>>>>>
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to boltwire+u...@googlegroups.com.
>>>>>>> To post to this group, send email to bolt...@googlegroups.com.
>>>>>>
>>>>>>
>>>>>>> Visit this group at https://groups.google.com/group/boltwire.
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "BoltWire" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to boltwire+u...@googlegroups.com.
>>>>> To post to this group, send email to bolt...@googlegroups.com.
>>>>> Visit this group at https://groups.google.com/group/boltwire.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "BoltWire" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to boltwire+u...@googlegroups.com <javascript:>.
>>> To post to this group, send email to bolt...@googlegroups.com
>>> <javascript:>.
>>> Visit this group at https://groups.google.com/group/boltwire.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"BoltWire" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to boltwire+unsubscr...@googlegroups.com.
To post to this group, send email to boltwire@googlegroups.com.
Visit this group at https://groups.google.com/group/boltwire.
For more options, visit https://groups.google.com/d/optout.
