Post Reply 
Author simple dialog feature
mdadou
AT core team member

Find all posts by this user
Quote this message in a reply
Default  10 July 2013 08:18
1. Requirements

From rally: (US1985)
- create a simple dialog classor widget, it must support animations. Full list of propertiesto be specified at dev time. See kitchen sink for examples.
- enhance the existing PopupManager to support touch events
- special care to be taken on Safari Mobile to cope with the address bar (height of page changes when it shows or hides)

2. Use Cases

There's a need for a lighter version of the existing aria Dialog widget

Use cases should be used to create the sample pages and/or tutorials.
[/i]

Marc's Kitchen sink pages on overlays and tooltips

3. Technical solution

That's where the question is: What is the best way to implement this new Dialog ? I'm thinking of doing an HTML Dialog widget, with an HTML body content, and 4 properties only:
"animateIn" : {
                    $type : "json:Enum",
                    $description : "Animation to apply to the opening popup",
                    $sample : "slide left",
                    $enumValues : ["slide left", "slide right", "slide up", "slide down", "fade", "fade reverse",
                            "pop", "pop reverse", "flip", "flip reverse"]
                },
"animateOut" : {
                    $type : "json:Enum",
                    $description : "Animation to apply to the closing popup",
                    $sample : "slide right",
                    $enumValues : ["slide left", "slide right", "slide up", "slide down", "fade", "fade reverse",
                            "pop", "pop reverse", "flip", "flip reverse"]
                },
"position" : {
                    $type : "json:String",
                    $description : "the position of the popup. center/left/right/bottom/top"
                },
"fullScreenAxis" : {
                    $type : "json:String",
                    $description : "axis on which the popup must extend fullsreen. x/y/both"
                },
"bind" : {
                    $type : "base:Properties.$properties.bind",
                    $properties : {
                        "visible" : {
                            $type : "json:Boolean",
                            $description : "Bi-directional binding. shows/hides the dialog window"
                        }
                    }
                }
-bind a 'visible' property to the datamodel to show/hide the widget

so to create a new Dialog you'd do:
{@html:Dialog{
      bind :{
            visible : {
                      inside : myDataModel,
                      to : "show"
               },
        animationIn:"slideup",
        animationOut:"slidedown",
        position:"top",
        fullScreenAxis:"both"
      }
  }}

//here some HTML body content with a title, some buttons probably, etc

{/@html:Dialog}

-is this a an acceptable solution ?
-what do I need to bind to the data model: is the 'visible' property enough ?
-is it better to create a widget or a class ?
-for this dialog to support animations, it's probably best to enhance the existing popup.js class to support animations. So add these 4 properties in aria.popups.Beans.js, and use this new enhanced popup to display the dialog: am I correct ?

4. History

10/07/2013 Matthieu DADOU creation
10/07/2013 Matthieu DADOU update after Fabio's comments
(This post was last modified: 11 July 2013 09:33 by mdadou.)
fabio.crisci
AT core team member

Find all posts by this user
Quote this message in a reply
10 July 2013 09:09
Hi Matthieu,
rather than @html this should be a @touch widget.

- it took me some time to understand 'position', which anyway should include 'center' as well

- the widget should probably have a 'size' property or is it done in CSS by the user?

- regarding animations, like what's been done for the page engine, it should be possible to specify an 'out' animations. For more flexibility it could be nice to specify also the css classes that we add on opening and closing, so that people can skin them differently or create other type of animations

- in the kitchen sink all dialogs are 'modal' and 'close on click', should this be configurable?
mdadou
AT core team member

Find all posts by this user
Quote this message in a reply
10 July 2013 09:41
ok for a touch widget, but I understood from Marc that it didn't have to be touch specific.
-position property: ok

-about the size property: please do let me know what the best way is. As an ariatemplate user I always wanted to set the size of a widget via the CSS, I've never really understood why there is a size property in widgets.

-Animations: I need to look ata the page engine, as I don't know how it works.

-Making the dialogs more configurable: sounds like a good idea, so are you suggesting more properties on the widget ? Only those 2 (modal / close on click ) ?
Marc Laval
AT core team member

Find all posts by this user
Quote this message in a reply
Default  11 July 2013 11:22
For me, this is not a touch specific widget, but it has to work on mobile browsers too. It is more a simple dialog widget where the content is simply HTML provided by the application, so it could be put in the html widget library.

Then for the configuration, any property from aria.popups.Beans should be usable (unless some limitations are found).
In fact, the 4 new ones should be implemented directly in aria.popups.Popup, and then be available to be used inside the new widget.
fabio.crisci
AT core team member

Find all posts by this user
Quote this message in a reply
11 July 2013 12:59
So far the widget libraries are

- aria: for amadues UI following internal guidelines, desktop only
- html: standard html components with easy binding and listeners, not additional behavior
- embed: include external elements in the page
- touch: advanced components that play nicely with touch devices, as well as with desktop

Given that a Dialog has complex behavior (positioning, closing...) and that there's no equivalent in html, I'd say it's either embed or touch, more touch because it must provide the same feeling on touch enable or non enabled devices.

And yes, html:Template was a mistake
Olaf
Administrator

Find all posts by this user
Quote this message in a reply
Default  11 July 2013 16:14
(11 July 2013 11:22)Marc Laval Wrote:  Then for the configuration, any property from aria.popups.Beans should be usable (unless some limitations are found).
In fact, the 4 new ones should be implemented directly in aria.popups.Popup, and then be available to be used inside the new widget.

+1

(11 July 2013 12:59)fabio.crisci Wrote:  Given that a Dialog has complex behavior (positioning, closing...) and that there's no equivalent in html, I'd say it's either embed or touch, more touch because it must provide the same feeling on touch enable or non enabled devices.

Considering the definitions you gave I would:
- agree it belongs to "touch" and, at the same time
- point out that it's a poorly chosen name that suggests those widgets are not fit for desktop apps.

It's a bit off-topic but I'd rename this lib if we keep these definitions (which are fine to me.)
mdadou
AT core team member

Find all posts by this user
Quote this message in a reply
15 July 2013 13:28
I am now thinking that the only differences between the existing @aria:Dialog and the one we want to create are:

- possibility of having animations to display the dialog ( 'animateIn', 'animateOut' )
- support touch events
- having a free HTML content.

the 2 "new" position properties ('position' and 'fullScreenAxis') are actually already covered by the existing Dialog properties.

=> Rather then having a new widget, isn't it better to enhance the existing one with these new features ?
I'm not convinced by the utility of having a free Html content btw, can someone explain to me why it'd be useful ?
fabio.crisci
AT core team member

Find all posts by this user
Quote this message in a reply
15 July 2013 13:38
The main drawback of @aria:Dialog is that it's hard to skin: any change should be done through the skinning file and the markup is not a contract. Users cannot simply change some CSS to adapt this widget to their needs.

Dialog widget after all should simply be a specialized Div inside the Popup utility, so all the features already available are coded into aria.popups.Popup which should make it simple to create a new widget.

What we could start with is to add animations for every Popup, this could be our first delivery.
Marc Laval
AT core team member

Find all posts by this user
Quote this message in a reply
12 September 2013 13:22
Hello,

I still think that having more positioning options in the Touch:Dialog widget is required in order to implement hings such as action menu (top, bottom), side menu, notification center in the right bottom corner.

The suggestion of 2 new properties ('position' and 'fullScreenAxis') wasn't probably the most elegant solution.

Today, the dialog container is always absolute positioned to top and left, with calculations done if it has to be centered or any other specific alignment. This logic is in aria.popups.Popup class.
Here is a suggestion to modify this class:
- instead of creating 'fullScreenAxis', we could change 'maximized' to support 4 values: false, true, "x-axis", "y-axis"
- for what I called 'position', I see 2 solutions:
1) Modify aria.utils.DomBeans:Position to add right and bottom, which could the be used in the widget via 'absolutePosition'. But it seems complex as there are many impacts in the full framework.
2) Create one new 'origin' property with default value "topleft", other possible values: "topright", "bottomright", "bottomleft"

Please discuss the solutio which will be implemented in the following GitHub issue:
https://github.com/ariatemplates/ariatem...issues/720
benoit.charbonnier
AT core team member

Find all posts by this user
Quote this message in a reply
Default  13 September 2013 10:08
What you describe here Marc for the action menu, side menu, notification is more an Overlay widget than a Dialog one....
To me a dialog should need fit the whole screen, or even just a part of it. The edges of the dialog should never aligned with the viewport.

If you need to (and i think it's more or less what exist in other libraries) we should then introduce and Overlay widget
(This post was last modified: 13 September 2013 10:08 by benoit.charbonnier.)
Post Reply