search

neo09 / gwt-platform

Automatically exported from code.google.com/p/gwt-platform
0 stars 0 forks source link

Allowing more flexibility and removing some boiler plate when assigning the default slot #194

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Actually we have to do this in every presenter:
  @Override
  protected void revealInParent() {
    RevealContentEvent.fire(this, MainPresenter.CONTENT_SLOT, this);
  }

I'm proposing to do this inside the parent and add a new method : 
setReveallingSlot(Object slot)

We would call this method inside the constructor. As a side effect, it would be 
possible to change the slot of presenters if needed.

What do you think ?

Original issue reported on code.google.com by goudreau...@gmail.com on 4 Sep 2010 at 3:41

GoogleCodeExporter commented 9 years ago 
I considered it a while ago and decided against it because it reduces child 
presenter's freedom too much. What if you want to add yourself in a parent slot 
instead? Or reveal in the root slot? Or reveal as a parent? Or do some minor 
processing before revealing?

An option would be to have both mechanism live side-by-side. i.e. a default 
implementation of revealInParent that uses the assigned slot and the 
opportunity for the user to override this... But it just feels a bit less 
clean. (Increase the memory footprint of every presenters but only some uses 
it, etc.) 

Reducing boilerplate is ok, but in this case it's a very small reduction and 
the cost seems a bit high. Moreover, I think the current approach gives a 
clearer view of the mechanisms at play in GWTP.

Original comment by philippe.beaudoin on 7 Sep 2010 at 12:17

GoogleCodeExporter commented 9 years ago 
Yeah well, I wasn't clear. That was what I meant :D

Anyway that was more like a proposition to discuss.

We could even inject the slot, that way, no need to setReveallingSlot even 
though I liked the ability to change that slot dinamically.

Original comment by goudreau...@gmail.com on 7 Sep 2010 at 2:44

GoogleCodeExporter commented 9 years ago

Original comment by philippe.beaudoin on 22 Sep 2010 at 1:35

GoogleCodeExporter commented 9 years ago 
Thinking again about it... I'm not entirely against the idea. It would reduce 
the code size without losing flexibility, given we still let the user override 
revealInParent.

Instead of setReveallingSlot we could pass the info to the constructor of the 
parent presenter and have a couple of different flavors for the different type 
of reveal:
With no extra info (user is expected to override revealInParent)
With a Type (parent will fire RevealContentEvent)
With an element from an enum to set as Root, RootLayout or RootPopup.

I suggest we do it for 0.5.

Original comment by philippe.beaudoin on 15 Oct 2010 at 10:00

GoogleCodeExporter commented 9 years ago 
Bumping to 0.6, preparing release 0.5.

Original comment by philippe.beaudoin on 25 Jan 2011 at 6:33

GoogleCodeExporter commented 9 years ago 
Bumping to 0.7, preparing release 0.6.

Original comment by philippe.beaudoin on 6 Jun 2011 at 8:17

GoogleCodeExporter commented 9 years ago

Original comment by philippe.beaudoin on 1 Feb 2012 at 6:52

GoogleCodeExporter commented 9 years ago 
https://github.com/ArcBees/GWTP/pull/33

Original comment by branflak...@gmail.com on 28 Nov 2012 at 3:14

GoogleCodeExporter commented 9 years ago

Original comment by branflak...@gmail.com on 28 Nov 2012 at 4:23