Basic example of covariant mediation of features to views(mapping interfaces)

[pixels4nickels]

I had a few folks wanting a decent example of how to map "features" to views using interfaces in order to more easily reuse "features" (features is maybe not the best terminology).

The example uses 2 mediators mapped to interfaces.  One gives status information, the other score information. The application has 3 views, created and implemented in 3 different ways (in order to show how each would be done).  Each view implements 1 or both of the interfaces which allow for mediation to occur.

I hope this helps some folks wanting to understand how this can be accomplished in such a simple manner, thanks to Shaun and Stray's tireless efforts!

https://github.com/pixels4nickels/CovariantLoveFest

Best,
Ken Rogers

[Shaun Smith]

Hey Ken, Thanks for putting that together. I think there are some confusing aspects though:

The interfaces are called *Provider, which would lead one to think that the implementations provide something, yet the interfaces only contain setter methods. Also, they live in the "api" package, but when one looks in the "impl" package one sees two classes, similarly named, that don't actually implement the corresponding interfaces. Then, looking at the views, they implement the interfaces, but don't actually do any "providing". The mediators do the providing, but they don't implement the provider interfaces.

In some libraries the word "client" is used. For example: IStyleClient, which is something that can be styled. Of course, there is also the whole "*able" naming scheme: IStyleable.

Haven't thought too much about it, but how about naming/packaging something like this (just an idea):

src

  config (I really don't like "cfg"!)

  behaviours

    messages

      IMessageClient

      MessageProvider

    scores

      IScoreClient

      ScoreProvider

  view

    AnotherView - implements IScoreClient, IMessageClient

    SomeView - implements IScoreClient

    YetAnotherView - implements IMessageClient

Perhaps people who've been using covariant mediation can give some input on the following:

Client naming: *able or *client

Provider/behaviour naming and packaging

As the mediator-view relationship is no longer one-to-one, it's worth thinking about where these things live. Also, I don't think "api" and "impl" make sense here.

Oh yes, one last thing: throw a README in there :)

--
You received this message because you are subscribed to the Google
Groups "Robotlegs" group.
To post to this group, send email to robo...@googlegroups.com
To unsubscribe from this group, send email to
robotlegs+...@googlegroups.com
for support visit http://knowledge.robotlegs.org

[Ken Rogers]

Hey Shaun,

I agree with the naming issues. Not to make excuses, but yesterday someone was asking me to show "how" to do it, technically.  I hurried through making the example in about 30 minutes and did not put much though into the naming.  All of your points are well taken. And looking back, I probably should have worked out many of these points before sharing with a wider audience.  I will make a big pass and update the example to make it more clear (especially package and mediator naming).

I will also add a README to explain what the whole kitten-kaboole is about.  Thanks for the helpful insight. It is very appreciated.

Best,
Ken

[Ken Rogers]

Okay! I have made some good changes(thanks Shaun!) to the packages and interfaces to make it more easily understandable.  I will write up a README and pop it in there as well...gotta scoot off to a meeting!

Best,
Ken

[Shaun Smith]

Nice one, looks good :)

[pixels4nickels]

readme.md added

[Shaun Smith]

Groovy, looking good. Two quick thoughts: I'd remove the "Structure" section of the readme - it's likely to go out of sync with the codebase. On a similar note, I'd use the MVCSBundle for now (rather than your custom one) as we may be changing things around a bit, and your bundle might also go out of sync.

On 1 Jun 2012, at 18:17, pixels4nickels wrote:

> readme.md added

[Ken Rogers]

Structure - sounds good. On a side note, I am not liking all the extra blank lines when making lists..not sure how to get it more "compressed". But in this case I am gonna just ditch it. Will revamp bundle def. That is the only cobweb left in the project, hehe.