scottplan wrote on 21 Nov 2009 15:42
ListPages' strength is in its ability to filter information: to focus on only those pages and that content that's relevant. So ListPages' "select" arguments are critical(category, date, tags, etc). Even so, it seems like ListPages' filtering is limited. I'm thinking I can't yet build a more sophisticated query that allows for a range of logical connectives (if, and, or, not…)
Some of these operators are possible, particularly within a single argument. For example, it's possible to list pages with tag1 AND tag2, or alternatively tag1 OR tag2.
But why not extend that flexibility across arguments? For example, I'm looking to create a list of pages created between one date and another, OR pages containing certain tags.
(%%created_at%%>{$startdate} AND %%created_at%%<{$enddate}) OR %tags%%={$CertainTag}
I think the above example gets at three requests:
- Allow for filtering within a date range with a specified start and end date (this isn't possible yet, is it?)
- Allow for parenthetic logical groupings.
- Allow for filters across more than one argument and joined by OR connectives rather than the default AND.
This makes the module more comples for the regular user.
Can you provide an example code… showing the whole lot? I'm not sure where your example is menat to fit into the module syntax?
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
To recap and talk in more general way maybe this can help:
in ListPages Improvements they define:
Selectors
List ordering
Header and Footer
Page properties
Maybe there should be also a section (maybe in Selector, maybe not)
Selector functions
The outcome of a selector is true or false. It should be possible to do logical funtions on these values. AND OR NOR NAND…
Selctor tags="x -y +z" can be described as
if (all tags<>y AND one tag=z AND one tag=X)OR(All tags<>y AND one tag=z) then it is okay
So tags="x -y +z" is a simple way to write the complex logical function. But if you understand the upper than you understand also that that is not one selector, but many selectors within a logical function …
If we would add another selector like "Created-at" there will always be an AND function between the two selectors (the tag AND the created at) (wich also indicates that we still need a "created between"-selector). This is a handycap and is not logical (highly illogical Spock would say)
It's nearly SQL in this advanced stage… but a regular user does not need to use nore know this if he/she does not want to.
So I support this sugestion
I'm not sure if "Output formatting:" is also a section (it lacks the marking of a title so…) But I wish to read there that there will be no <p> inside a listitem by default !!!!
A - S I M P L E - P L A N by ARTiZEN a startingpoint for simple wikidot solutions.
The more flexibility we have to filter, the more useful our active, crowd-sourced wikis become. Maybe we want to list pages in a certain category, but also other pages with certain tags.
I agree that it can be complex to build these logical filters. But once they're in place, they would make our data streams much more useful and more intuitive for users.
The example I've given would be for a weekly newsletter. I want each newsletter to feature a certain weekly slice of submitted articles. But I'd also like to recycle older articles that are tagged for inclusion in a certain newsletter. So an OR statement would be handy.
@Scott, I'm moving this thread to be a subthread of the existing ListPages improvements design.
Facepalm.
Sorry… :-( I did not even realize this is exactly what you'd done.
Sorry, sorry, mea culpa for firing first and reading second.
Portfolio
My view on the proposal here…
What we need, from my experience, is:
So the user's model is not affected. Selectors are always AND (or AND NOT), but we need a syntax (if we want to support this) to allow multiple sets of selectors to be ORd together.
E.g.
Portfolio
Thanks Pieter,
This does get complicated. Working through these examples, I see how you'd want to keep the selecting complexities away from the core functionality of the module. The idea of a nested SELECT subfunction is a good one — programmer-types and wannabees can go there at their peril.
You identified a key point. The different selector sets need to be merged within a single list to avoid any duplicates.
Not to mix issues (but I will), this is precisely the confusion that I was getting at earlier.
Is there a simpler way to navigate up- and downstream along these threads and subthreads, or to map the larger discussion somehow?
Yes, I also connected the two dots.
I'm finding the suptopic model takes a little time to learn but is working better now. We treat subthreads as issues, and close them, and that's really nice. It's not really splitting but a fractal "zoom" thing.
For overall navigation, check the main page, "+ Show layout". Problem is it does not hide closed threads, etc.
Other ideas I have for improving the mental model we have of the structure:
But overall it seems that we need to learn the local structure for different parts of the tree. E.g. now we're opening and closing issues on the ListPages design, which is great, but we're also discussing here, on a closed subthread.
Portfolio
What would this do?
The pages that ought to be selected should be of category "work" AND should have tags "_issue" OR "_open" OR "_wish" OR "_pending", that is the same as
Because inside the tag-selector we already have the OR function
But let's say I want Pending Issues or Open Wishes, in other words My todo list. That would be maybe
A - S I M P L E - P L A N by ARTiZEN a startingpoint for simple wikidot solutions.
More analysis on this…
The traditional maths-driven solution is to offer users a fully generic grammar that they can combine in any way they like. Thus we get stuff like the SQL "where" clause.
I hate this. It demands that users understand abstract tools, and re-invent models each time. It requires ordinary people to be programmers.
Imagine if Google insisted that every search was constructed as a valid logical expression. I recall people tried this in the past… not very successful.
My preferred approach is to reduce complexity and flexibility and provide the user with pre-defined patterns that cover the 'normal' use cases. Power is not the goal, simplicity is.
So applying this to ListPages selectors, we have three patterns:
Asking or allowing the user to change the pattern (merging selectors or intersecting sets) breaks the pattern, adding power for no purpose. Programmers will be disappointed because they expect more flexible tools. But normal users will be grateful because it "just works" as expected.
My example was incorrect, it should have been:
Portfolio
Yes this would work for me… OR between selectors
So now the example is indeed correct… my correction would have shown also "_open" threads for example.
This is a nice design I see the benefits of it. Nice work
A - S I M P L E - P L A N by ARTiZEN a startingpoint for simple wikidot solutions.
I've merged this design into the main text and am closing this subthread.
Portfolio
Steven wrote:
But let's say I want Pending Issues or Open Wishes, in other words My todo list. That would be maybe
Why not just make both categories use the same tag? For consistency, issues should use the same tags as the wish category. Therefore:
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
You can imagine many pages without a common tag that, at a certain point in time, need to be listed…. I do not wish to be the person to insert for all tose pages the common tag… so these combined logical functions are essential for bigger sites IMO.
A - S I M P L E - P L A N by ARTiZEN a startingpoint for simple wikidot solutions.