you can't put it on one line like that, it uses regular expression which
can be complex and long. If you have many user agent string conditions
its going to get very messy in the ui. I would rather have multiple
lines and two separate lists.
This is for admins, not casual users, and this is for configuring
advanced options. We will have to document how it works, but if they
don't know how to use regular expressions, they don't know enough how to
configure this.
On Fri, 2012-04-13 at 16:48 -0300, Gabriel Cardoso wrote:
Hopefully this makes it more clear.
Indeed it makes it more clear :)
Can you change the mock up to add two separate lists for contains
and must not contain?
I'm sending a different interaction proposal. If we add two lists, we
need two Add buttons to specify in which list are you adding a item or
if we keep a button, we need to have one more step (drop down) to
specify in which list to add the item.
Considering that the user needs to fill at least one contains
condition, I put an initial input inviting him to fill it. Once he
press enter, the input becomes a element that can be removed by
clicking in the "x". This way I think we have a much faster and easier
interaction. I'm just not sure how many conditions will we have. I
expect to have one line of conditions for each type but having two
lines would not be a problem.
So if we have a match for anything in the contains list, and we
don't
have a match for anything in the 'does-not-contains' list, then the
condition for user agent strings is true.
I tried to make it evident by presenting the following message in the
initial state: "At least one element for the redirection to happen."
and by labeling the second line as "and does not contain".
If you want to do something like direct for every User-Agent except
if
it contains abc, then you would add '*' to contains (regex to match
everything) and add 'abc' to does-not-contain.
The does-not-contain list can be empty.
This requires some high IT knowledge. So just to be sure, the person
who will set it up is a Admin, a IT guy? Does he already knows that
(*) means like "all"? Should not we use another notation, like work
"all" or something like that?
For device properties, if the list is empty then it means we are not
checking any device properties, and the device property check will
return true. When creating a new condition, this list should be
empty.
It would be nice if for an empty list we have an entry in the table
saying something like 'No Device Properties specified. Device
Properties
are not being checked'.
That's a good idea that I borrowed to apply in the "contains"
condition too.
Thoughts?
Gabriel
On Apr 12, 2012, at 5:22 PM, Matt Wringe wrote:
cc'ing back in the gatein-dev list, you should usually use
'reply-all' (or reply-to-list) so that the list gets added. It's
usually
best to discuss things on the list so that the whole group can
comment.
On Thu, 2012-04-12 at 15:41 -0300, Gabriel Cardoso wrote:
Hi Matt.
Would that work? Just adding the words OR and AND before the specs?
Thanks
No, not exactly (but its my fault its confusing and I should have
specified two separate lists from the original mockups). Can you
change
the mock up to add two separate lists for contains and must not
contain?
Really what is comes down to is:
Contains:
foo
or bar
or ...
Must Not Contain:
abc
or xyz
or ...
So if we have a match for anything in the contains list, and we
don't
have a match for anything in the 'does-not-contains' list, then the
condition for user agent strings is true. Its the same thing as a
white
list and a black list.
For example, using the above configuration
User-Agent: fasdfl asdf asdf asdf foo asdf asdf a dsf
-> is true because it contains foo _and_ does not contain abc and
xyz
User-Agent: fasdfl asdf asdf asdf foo abc asdf asdf a dsf
-> is false, even though it contains foo, because it contains abc it
fails
User-Agent: fasdfl asdf asdf asdf asdf asdf a dsf
-> is false, there is no match on a contains
User-Agent: fasdfl asdf abc asdf asdf asdf asdf a dsf
-> is false, it contains abc which is in the does-not-contain list
(and
it also doesn't contain anything in the contains list)
If you want to do something like direct for every User-Agent except
if
it contains abc, then you would add '*' to contains (regex to match
everything) and add 'abc' to does-not-contain.
The does-not-contain list can be empty.
For the situation when you create a new condition, the contains list
and
the doesn-not-contain list should probably both be empty (since the
contains list is empty, the default will be to never redirect until
the
admin configures something here).
For device properties, if the list is empty then it means we are not
checking any device properties, and the device property check will
return true. When creating a new condition, this list should be
empty.
It would be nice if for an empty list we have an entry in the table
saying something like 'No Device Properties specified. Device
Properties
are not being checked'.
If we have one or more device properties specified, then _all_ of
these
properties must be met (ie its now using AND).
So it all works something like this (note: this is for higher level
logic, the implementation doesn't exactly follow these steps).
1) we check if the User-Agent string has a match in the list of
'contains'. If true continue, if not don't do the redirect
2) we check if the User-Agent string has a match in the list of
'does
not contain'. If we have a match, then don't do the redirect.
Otherwise
continue
3) we check if there is a match for all the device properties. If we
have a match, now we can do the redirect, otherwise don't do the
redirect.
Hopefully this makes it more clear.
On Apr 12, 2012, at 3:09 PM, Matt Wringe wrote:
JBoss Community
Gatein Mobile Detection And Redirection: Administration UI
new comment by Matt Wringe View all comments on this document
After a offline discussion, the following changes were determined:
- no more concept of device type
- prepopulate a new portal with a couple of default redirects
which contain default conditions for some specific devices (phone,
tablet, etc..)
screen 1:
- remove the icon and change 'Device' to something like 'Redirect'
which will display the redirect name.
- add a 'copy' option to clone a new redirect based on a exiting
redirect. Copy and Delete will appear under a separate menu where the
current 'delete' icon is currently located
screen 2:
- removed
- when creating a new redirect, screen 3 will be displayed.
screen 3:
- no icon beside the redirect name.
- when creating a new redirect: generic redirect name
('redirect-1' or something similar) but its an editable value, so it
change be changed. The redirect site will have to be set to the first
site name in the drop down [does this make sense? or should it be
empty/null by default?]. Redirect will be enabled by default when
creating a new redirect [right? since they obviously want to use the
redirect, otherwise why would they create one?] [Note this part as not
discussed, just adding my thoughts here]
- make the 'redirect to' more prominent (larger font size, etc.
Its too small and out of the way right now when its an important
option)
screen 4:
TODO: make clearer in screen 4 the behaviour when multiple
conditions are specified.
Current behaviour for user-agent string: Condition is true if the
user agent contains any of the strings specified in 'contains' and no
string specified in 'does not contain'
[multiple user-agent conditions act as OR]
Current behabiour for device properties: If ALL the device
conditions are met
[multiple device properties act as AND]
The idea behind this is that you would probably want to list
multiple different contains for a user agent string (ie for a list of
browser types, so OR) but you would probably want to use AND for
device properties (ie if width is less than X and device pixel density
is above y). But this gets a bit confusing. I would rather not have to
support more complex rules if possible.
_______________________________________________
gatein-dev mailing list
gatein-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev