quote:
Originally posted by Itsme-HcK
You've got a point there, but your way won't work either.
what wouldn't work? The multiple stuff? It is perfectly possible though. In case the user wants more group names or statusses, he can always create a quicktext calling the whois command/tag multiple times, since a contact can only be in one group at the time and only have one status at the time.
In fact, you do not need a command at all for this whole plugin idea, only 1 tag (with 2 parameters).
bare with me (it's very long as all this is hard to explain (and I like writing long stuff they say -I wonder why-
)):
quote:
Originally posted by Itsme-HcK
(...) indeed more statuses allowed per xwhois, by simply doing something like this:
/xwhois group:friends status:online,busy,brb
Or by making more "status:" statements:
/xwhois group:friends status:online status:busy status:brb
You could also specify more groups:
/xwhois group:friends,family
/xwhois group:friends group:family
I don't recommend using the comma as delimiter. It would work for the statusses (because a comma isn't part of any status text), but not for the groups. Because a comma is a much used character, also in group names themselfs.
And there is another common and more important problem which I already explained, but I wish to emphasize again using your latest examples as a guide:
Using text as a parameter isn't that strait forward to implement as you might think (though, I don't know what you might think of course
). Especially if prefixes used in parameters can actually also be part of the text you need to enter after the prefixes. And especially in cases were parameters do not have a fixed order, you really making it yourself much harder to code this and to avoid bugs.
eg: /xwhois group:friends group:family
What is the actual first group name here? "
friends" or "
friends group" or maybe even "
friends group:family"? All three are perfectly possible, valid and even logical group names... Remember that you can use any character in groupnames, including comma's, spaces, quotes, etc...
This is exactly what I meant with
"using that method will make your plugin, aka the parsing of commands, very complex and prone to errors/bugs" (but not impossible to make).
And if you are including that mask-as-a-parameter idea in all this, the problem gets even worse (and almost not possible anymore to make it properly).
-------
Thus because of all this, I think this is a case were too much freedom in your command and/or tags structure results in buggy usage and code. And thus the reason why I would only make it useable for single parameters (at least for the group name in your latest method) and with a fixed order. Aka: you don't need to make it so complex in order to provide freedom to the user (but more about this later).
The status parameter could contain multiple statusses. Though it is not really needed as the user could call the whois command/tag multiple times anyways. But if you really want it in one syntax anyways, then only delimit it by a comma (or other character for that matter). Thus only using one single "status:" prefix and not the possebility to enter more "status:" prefixes. Otherwise you would have again the same problem as described in the first section of this post; where does one prefix/parameter end and where does another one begin.
The mask idea is nice, but again prone to problems as described above. Where does the group name end, and where does the mask begin? Note: using a "mask:" prefix would work, but limits again the group names themselfs. And actually even limits what you can do with the mask! Unless you use it again in combination with quicktexts. But then again why using a "mask" parameter in the first place when the user needs to make quicktexts anyways in order to have total freedom (eg: I'm thinking of the use of carriage returns for example).
Hence why I would not implement the mask idea at all and certainly not as a parameter.
-------
Thus to conclude this long rant (almost): after analyzing all this from scratch using your latest method and thinking about it for the second time, I come again to the same syntax as I mentionned before (only now, I even realize you do not even need a command at all, only 1 tag):
(!XWHOIS_STATUS_GROUPNAME)
Where the layout of the output (what you called the "mask") is set in a preference dialog (thus not as parameter). And this "mask" is only for the relevant output itself, not for the words or whatever that would come before or after the output and make up a sentence, as that can be done using quicktexts anyways.
So the mask is not something like a textbox (or parameter) where the user can define:
"These are all the people from the group $groupsname$ who are $status$: $names$"
because all that can be done in a quicktext anyways:
These are all the people from the group family who are busy: (!XWHOIS_BUSY_FAMILY)
which also enables the user to use multiple lines if he wants, because...
The "layout" is defined in a preference panel where the user must select what is been shown (what the result of the tag will be):
option: [ ] show friendly name
option: [X] show email
small textbox or combobox or something: delimiter = [ ... ]
Where the delimiter can be a carriage return (aka line feed) for example or even something like: "
<ctrl+o>,<ctrl+k>5" making the individual parts even colored if they want, etc... etc...
In fact, like this the user can make his own /xwhois command (or multiple commands)!
-------
Additional note about supporting possible other more specific tags like one for the group name, one for the status, etc: Since the groupname is specified as a parameter inside the main tag anyways, the user also already knows which group name he is selecting (otherwise he wouldn't be able to enter the group name as a parameter of course). This means you don't need a (!xgroup) tag either to make up some mask or layout or something inside quicktexts... same story with the statusses btw.
thus not:
These are all the people from the group (!xgroup) who are (!xstatus):
#(!XWHOIS_AWAY_FAMILY),(!XWHOIS_AWAY_FRIENDS)
but:
These are all the people from the group family and friends who are away:
#(!XWHOIS_AWAY_FAMILY),(!XWHOIS_AWAY_FRIENDS)
-------
So, you see, with an extremely simplyfied and fixed method, you actually give the user far more possebilities. And above all, it would be dead easy to program something like this (compared to the extremely complex parsing you would need with multiple same parameters, random orders, etc)
-------
Anyways, all this is IMHO (in my humble opinion) of course; This is how I think about all this, not how you
must program it. Just giving my point of view about this (as I find this a potential usefull plugin and interesting subject to think, wonder and talk about)...
EDIT: Come to think of it, another advantage of my single tag method is the ability to enter only a part of the group name instead of the full group name, since it is very clear what the full groupname parameter is (as you can't have multiple ones, and the order is fixed, and it is the last parameter). In your method, this would even add more troubles (on the already existing parsing problems) in determining what the complete groupname parameter would be.
/ 
