On Wed, Nov 13, 2013 at 11:37 AM, Alex Harui <aha...@adobe.com> wrote:
>
>
> On 11/13/13 8:17 AM, "Peter Ent" <p...@adobe.com> wrote:
>
> >
> >
> >On 11/13/13 3:19 AM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote:
> >
> >>On Tue, Nov 12, 2013 at 8:27 PM, Alex Harui <aha...@adobe.com> wrote:
> >>
> >>> Hi Om,
> >>>
> >>> Looks good. Some points to ponder:
> >>>
> >>> 1) Ideally, in a Pay-as-you-go philosophy, a rolloverIndex would not be
> >>>in
> >>> the ArraySelectionModel since, in theory, ArraySelectionModel should be
> >>> reusable in mobile devices where there is no rollover. I honestly
> >>>don't
> >>> know what the right answer is. There are options like having a
> >>>subclass
> >>> of ArraySelectionModel that supports rollover. There is the option of
> >>> having rolloverIndex stored somewhere else. Maybe rollover is a
> >>> presentation concept, or maybe rollover should be entirely encapsulated
> >>>in
> >>> its own bead so it can be dropped out of mobile configs? But I think
> >>>the
> >>> entire mousecontroller will be replaced by a touchcontroller in that
> >>>case.
> >>> Another thing to consider is that, if a JS DG happens to wrap a
> >>> third-party DG or I think there is one built into HTML5, and the JS
> >>> version doesn't support rollover, how can we extract rollover from the
> >>>AS
> >>> version?
> >>>
> >>
> >>Yes, this was bothering me as well. I couldnt think of a great place to
> >>put this info. Since it is not possible to have multiple models for a
> >>component, having a subclass of ArraySelectionModel called
> >>ArraySelectionAndRollOverModel would probably work. But it will soon
> >>start
> >>getting unwieldy if go this route.
> Agreed
> >>
> >>The other option is to change ArraySelectionModel to
> >>ArrayInteractionsModel
> >>and have an array of composed models, ex. SelectionModel, RollOverModel,
> >>TouchModel, etc. This way, we can string as many models as needed on a
> >>pay-as-you-go basis.
> >>
> >>What do you think?
> >
> >My thought on roll-over was to let the mouse controller dispatch the event
> >on the strand and any itemRenderers that were interested in handling
> >roll-over would listen for it and implement it themselves. That doesn't
> >necessarily lead to a unified look to something like the DataGrid, but it
> >supports pay-as-you go. That is, on mobile devices the mouse controller
> >would be replaced with a touch controller and no roll-over events would be
> >issued (unless you have a new device that detects 'hover' or hand-waving
> >or something in the future). If you leave the itemRenderers the same in
> >the mobile version as the desktop version, the roll-over event listeners
> >are harmless. The grid presentation model could contain the feedback color
> >for handling roll-over and the itemRenderers could access that and use it
> >to provide a uniform look.
> That's another viable implementation. It has the drawback that the
> renderers carry rollover code into environments where it isn't needed, but
> the renderers rollover implementation could also be a bead.
>
> I can think of several options:
> 1) Your sugestion of array of composed models
> 2) simply add another bead of type IRollOverModel or something like that
> that a rollOver implementation looks for
> 3) bake the rolloverindex into the rollover bead
> 4) Go heirarchical: The rollover bead has its own model.
>
> To me, the primary model for a component is the data model which
> represents the public properties for the component (the attributes that
> would be set from MXML and/or properties most often checked by event
> handlers and other code). The internal workings of a component can have
> its own data to share, but they don't have to be separate models, the
> point of assignable models is so that richer views can work with richer
> models. Other internal feature implementations only need to have some
> agreement between the beads that it is comprised of.
>
> The simplest rollover implementation that just slaps a highlight rectangle
> on a renderer doesn't need a separate model at all. It can probably be
> self-contained. However, the renderer wouldn't get a choice of altering
> its visuals to react to the highlight, like changing font color to
> contrast better against the highlight.
>
> So, the renderers probably do need to know if they are highlighted. Some
> implementations may share a rollOverIndex, others may not and simply set
> the hovered property on a renderer or otherwise alter the calculation of a
> "currentState" property.
>
> So right now, I would say that rollover isn't really part of selection and
> doesn't nee d to be composed into the main model. And hanging in the
> central rollover bead or having that bead have its own model is sufficient.
>
> >>
> >>
> >>>
> >>> 2) There is an entirely alternate implementation of rollover where it
> >>>is
> >>> completely delegated to the renderer to determine based on mouse events
> >>> what its display/rollover and selection state is. Think of renderers
> >>>that
> >>> have buttons in them for deleting that row. Clicking on the button may
> >>>or
> >>> may not change the selection, rollover the button may not cause
> >>>rollover
> >>> highlighting of the row, just the button. I'm not saying this a
> >>>preferred
> >>> implementation, just that we want to make sure we make as many other
> >>>beads
> >>> reusable as possible in such an implementation, and not lock folks into
> >>> one implementation or another.
> >>>
> >>
> >>So, each renderer has selection, rollover, etc. models?
> Maybe as a model or maybe just as a current state. MX renderers had to
> ask the containing list if they were highlighted or not. Spark renderers
> have a hovered property that affects getCurrentRendererState.
>
> -Alex
>
>
The usecase here is that there are n Lists (for each column) composed by
the DataGrid component. If the users rollsover an on any list, the
corresponding itemrenderers in each column must highlight themselves. So,
keeping track of the current rollOverIndex as part of DataGrid's model is a
must.
After reading your comments multiple times, here is one approach we could
do.
default.css:
List
{
IBeadModel:
ClassReference("org.apache.flex.html.staticControls.beads.models.ListInteractionModel");
//other stuff
}
public class ListInteractionModel extends ArrayInteractionModel implements
ISelectionModel, IRollOverModel
{
private var selectionModel:ISelectionModel = new SelectionModel();
//Implements ISelectionModel (proxies selectionModel)
function get selectedIndex():int;
function set selectedIndex(value:int):void;
function get selectedItem():Object;
function set selectedItem(value:Object):void;
private var rollOverModel:IRollOverModel = new RollOverModel();
//Implements IRollOverModel
function get rollOverIndex():int;
function set rollOverIndex(value:int):void;
}
public class ArrayInteractionModel extends EventDispatcher implements
IArrayInteractionModel
{
//Implements IArrayInteractionModel
function get dataProvider():Object;
function set dataProvider(value:Object):void;
//Implements IBeadModel
function set strand(value:IStrand):void
}
public interface IArrayInteractionModel extends IBeadModel
{
function get dataProvider():Object;
function set dataProvider(value:Object):void;
}
So, if we have a mobile list, we would define its model this way:
public class MobileListInteractionModel extends ArrayInteractionModel
implements ISelectionModel
{
private var selectionModel:ISelectionModel = new SelectionModel();
//Implements ISelectionModel (proxies selectionModel)
function get selectedIndex():int;
function set selectedIndex(value:int):void;
function get selectedItem():Object;
function set selectedItem(value:Object):void;
}
What do you think?
Thanks,
Om
