Re: [aerogear-dev] [Java Sender] Message Fluent API / Builder / DSL ...

Do we have a JIRA for the "fluent API" refactorings ? On Tue, Jul 9, 2013 at 10:46 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: > Sure ! > Thanks for the updates I will for sure add this to the builder API > > > On Tue, Jul 9, 2013 at 10:17 AM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > >> Besides "alias", it is also possible to "filter" based on "deviceType". >> >> For the fluent API, I think something like ".deviceTypes(varargs)" is >> needed as well >> >> -Matthias >> >> >> >> >> On Tue, Jul 2, 2013 at 4:34 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: >> >>> >>> >>> >>> On Tue, Jul 2, 2013 at 3:13 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: >>> >>>> Hi Folks, >>>> As you know we have a Java Sender Library that can be used by any >>>> backend application that want to send messages to the Unified Message Push >>>> Server (https://github.com/aerogear/aerogear-unified-push-java-client >>>> ). >>>> The format is quite open and flexible as Matthias described it here : >>>> https://gist.github.com/matzew/b21c1404cc093825f0fb >>>> >>> >>> >>> the real doc is located here: >>> http://staging.aerogear.org/docs/specs/aerogear-push-messages/ >>> >>> >>> >>>> >>>> We can divide the creation of a message in 2 main parts : >>>> >>>> - The "signalling" part : list of client identifiers / specific >>>> devices etc ... >>>> - The "core" message containing actually the information we want to >>>> push >>>> >>>> Both are passed as Map and are finally converted into JSON. >>>> Here an example of how a "core" message is build : >>>> >>>> Map categories = new HashMap(); >>>> categories.put("lead", "version="+leadVersion++); >>>> Map json = new HashMap(); >>>> json.put("id", lead.getId()); >>>> json.put("messageType", "pushed_lead"); >>>> json.put("name", lead.getName()); >>>> json.put("location", lead.getLocation()); >>>> json.put("phone", lead.getPhoneNumber()); >>>> json.put("simple-push", categories); >>>> json.put("sound" ,"default"); >>>> json.put("alert" ,"A new lead has been created"); >>>> >>>> >>>> Even the format is open, we could "assist" a bit the developer in >>>> building the message. For that we have different options : >>>> - Propose a simple Message object containing the message "API" : >>>> >>>> Message message = new Message(); >>>> message.setClientIdentifiers("jake","maria"); >>>> message.enableSound();//by default use "default" or we could do message.enableSound("boing") >>>> message.setAlert("Watch out!); >>>> message.setAttribute("customAttribute","yo"); // custom simple strings >>>> message.setAttribute("customStructure",myObject); // passing objects >>>> >>>> >>>> - Propose a Message Builder (following the Builder Pattern) to propose >>>> a more fluent API : >>>> >>>> Message message = new Message().builder() >>>> .clientIdentifiers("jake","maria") >>>> .enableSound() >>>> .alert("AAAAHHH!") >>>> .attribute("customAttribute","yo") >>>> .attribute("customStructure",myObject) >>>> .build() >>>> >>>> >>>> >>> >>> I like the builder! +1 >>> >>> >>> >>> >>> >>> >>>> - Same as above but more DSL focused (not sure about this one ;) ) >>>> >>>> Message message = MessageDSL.to("jake","maria").withSound() //etc ... >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> +0.5 >>> >>> >>> >>> >>> >>>> So, beside that we have to discuss what we want allow to pass to the >>>> message API : only Strings and simple Maps ? Full Objects that will be >>>> JSONified ? >>>> >>>> Do we want also to separate the "signalling" part from the "core" part >>>> when building a message ? >>>> >>> >>> I think that would be good, without too much thinking about it. >>> >>> * MessageBuilder -> builds message >>> * "signalling" part, on it's own (Filter + FilterBuilder (LOL)) >>> >>> and both parts are combined into the actual "payload" object, to be >>> send out. >>> >>> However.... that can make the bits unnecessary complicated.... >>> After writing the above lines, why not starting with a >>> Message/MessageBuilder. If separation is needed later, we can always do it >>> later. >>> >>> Greetings, >>> Matthias >>> >>> >>> >>>> >>>> Inputs and comments more than welcome ! >>>> >>>> Seb >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev