K4kArot2015 / sigplus

Automatically exported from code.google.com/p/sigplus
0 stars 0 forks source link

Wildcards patterns - option to exclude or extension patterns #22

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Filed a request to add the possibility of establishing a model of the file name 
to the exclusion of unwanted phrases.

eg

is currently:
 {gallery id=parks}sampledata/parks/landscape/*australia*{/gallery}

proposal to exclude files based on phrases in the file name:
 {gallery id=parks}sampledata/parks/landscape/*australia*;not *europa*; not *city*; not *{/gallery}

or
the ability to add more phrases that must appear on the file name that is 
displayed in the gallery:
 {gallery id=parks}sampledata/parks/landscape/australia*;*architecture*{/gallery}

With this option, you can quickly create thematic galleries based on the words 
of keys stored in the file name.

In addition, the same mechanism can be applied to the file extension for 
example, only *. Jpg,

Reagrds!

Original issue reported on code.google.com by ten.mari...@gmail.com on 25 Apr 2012 at 5:17

GoogleCodeExporter commented 9 years ago
I am afraid this proposal raises many open questions and works against sigplus 
having a simple and clean syntax. In particular, it is not clear how to decide 
whether special keywords like "not" are indeed keywords or only part of the 
file name (e.g. "not a coincidence"), and a similar reasoning applies to spaces 
and semicolons, which are characters casual users are likely to put into file 
names without any intention of using pattern matching. Also, the syntax can 
create an illusion that more complicated expressions are possible, e.g.

sampledata/parks/landscape/*australia*;not /europe/hungary

Here, it is not obvious where the second path is to be rooted. Besides, the 
current implementation of sigplus does not directly permit galleries whose 
images come from unrelated sources (e.g. different directory hierarchies).

In addition, I have a performance concern: the more complicated the expression 
is, the more resources it consumes to build the gallery. Unlike regular image 
sources without wildcard patterns where it is possible to use database indexes 
to quickly identify images of interest, those with wildcard expressions do not 
make this optimization possible.

Original comment by huny...@gmail.com on 29 Apr 2012 at 12:40

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
This option is new right?
Where can I find the syntax to it?

Original comment by ten.mari...@gmail.com on 24 Jul 2012 at 10:30

GoogleCodeExporter commented 9 years ago
You might want to check out issue 25, which is already implemented and uses a 
syntax much less ambiguous (and an approach more more efficient) than proposed 
in this tracker.

Original comment by huny...@gmail.com on 24 Jul 2012 at 3:54