Hopefully this makes it more clear.

Can you change the mock up to add two separate lists for contains and must not contain?

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.

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 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 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 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'.

Hopefully this makes it more clear.

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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev