[aerogear-dev] Push Admin UI - Updating

[Matthias Wessendorf]

On Tue, Jul 16, 2013 at 9:57 AM, Sebastien Blanc <scm.blanc at gmail.com>wrote:

>
>
>
> On Tue, Jul 16, 2013 at 8:36 AM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>>
>>
>>
>> On Mon, Jul 15, 2013 at 8:34 PM, Lucas Holmquist <lholmqui at redhat.com>wrote:
>>
>>> here's a scenario.
>>>
>>> A user creates an "Application" then adds a new "iOS Variant" to it.
>>>
>>> they decide they need to rename this Variant since they didn't name it
>>> very well.
>>>
>>> There is currently no way of renaming/ updating the description of this
>>> variant without re-sending the Certificate/pass phrase.  this would be the
>>> same for Android and Simple Push,  just substitute google key and channels
>>>
>>
>> yes - but should be easy to change :-)
>>
>> See here:
>>
>> https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/main/java/org/jboss/aerogear/connectivity/rest/registry/applications/AndroidVariantEndpoint.java#L134-L138
>>
>> in the "update", we just need to onbly update/replace those things that
>> are NOT null. Of course, perhaps we need to rethink the "update validation"
>> too:
>>
>> https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/main/java/org/jboss/aerogear/connectivity/rest/registry/applications/AndroidVariantEndpoint.java#L130-L132
>>
>> Yes that could work even if I must admit I'm not a big fan of updating
> based on a null check ... Imagine someone wants to delete the description
> by setting it to null , that won't be possible ;)
>

well, yeah - that (the desc) is optional - I was more interested in the
required fields:
e.g. for iOS Variant:
* cert/passphrase (or googlekey/networkURL on other variants)
PushApp:
* name





> (Well not sure it is a valid use case but you see my point) and as you
> said we must then rethink user validation.
> Other option is to split the update into more smaller specific updates
> methods ... but not sure about this also.
>





>
>
>
>>
>>
>>>
>>> Also,  once we have a variant created,  we have a variant ID,  we should
>>> be able to use that ID( plus type? ) to do updates instead of having to
>>> pass the applicaitonID and variantID( same would go for a delete i guess ).
>>>
>>>
>>> Not really sure the best way to handle this.
>>>
>>
>> the "variantID" is not a PK, but it's unique - so a new finder is what
>> you need.
>>
>>
>>
>>>
>>> Should a user be able to update a certificate/key/channel once it has
>>> been created.
>>
>>
>> yes, they should be able to replace an outdated (or revoked) certificate,
>> API etc.
>>
>>
>>
>>>  How would this affect any installations it might have?
>>>
>>
>> Not at all.  so if (speaking Androind) ... a new "project" is used -
>> there is a new SenderID - that's more impact, since the actual mobile app
>> needs to be updated, but again that's not really a concern for the push
>> server
>>
>>
>>
>>>
>>> thoughts?
>>>
>>> -Luke
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130716/ad53611f/attachment.html