simple dialog feature - Printable Version
+- Aria Templates Forums (http://ariatemplates.com/forum)
+-- Forum: Public forums (/forumdisplay.php?fid=3)
+--- Forum: Specifications (/forumdisplay.php?fid=13)
+--- Thread: simple dialog feature (/showthread.php?tid=33)
Pages: 1 2
simple dialog feature - mdadou - 10 July 2013 10:18
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.
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:
so to create a new Dialog you'd do:
-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 ?
RE: simple dialog feature - fabio.crisci - 10 July 2013 11:09
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?
RE: simple dialog feature - mdadou - 10 July 2013 11: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 ) ?
RE: simple dialog feature - Marc Laval - 11 July 2013 13: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.
RE: simple dialog feature - fabio.crisci - 11 July 2013 14: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
RE: simple dialog feature - Olaf - 11 July 2013 18:14
(11 July 2013 13:22)Marc Laval Wrote: Then for the configuration, any property from aria.popups.Beans should be usable (unless some limitations are found).
(11 July 2013 14: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.)
RE: simple dialog feature - mdadou - 15 July 2013 15: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 ?
RE: simple dialog feature - fabio.crisci - 15 July 2013 15: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.
RE: simple dialog feature - Marc Laval - 12 September 2013 15:22
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:
RE: simple dialog feature - benoit.charbonnier - 13 September 2013 12: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