Hi Janaka,

+1 for that approach.

Thanks

On Tue, Nov 6, 2012 at 12:37 AM, Janaka Ranabahu <jan...@wso2.com> wrote:

> Hi Shelan,
>
> IMO, #1 is the best approach to fix this. There are couple of reasons for
> me to say that.
>
>    1. This has been already implemented and it is working without any
>    issue. Therefore the only reason we need to change that is to comeup with a
>    better solution.
>    2. IMO, using full stop (".") to separate the words is more user
>    friendly than using camel case phrases.
>    3. If we change this, there is an aspect of data migration since this
>    will change the properties of some resources(which have been associated
>    with a lifecycle) and will change the content of all the lifecycle
>    configurations.
>
> Thanks,
> Janaka
>
>
> On Mon, Nov 5, 2012 at 5:24 PM, Shelan Perera <she...@wso2.com> wrote:
>
>> Hi,
>>
>> Could you please give the feedback on the suggested approach?
>>
>> 1) Let the user to add the fullstops and prevent adding spaces.
>>
>> 2) If user adds spaces remove it and do the parsing (Since it is not
>> compliant with SCXML and then add the use the one with spaces.)
>>
>> I prefer 1st approach since 2nd seems like a hack.
>>
>> Thanks
>>
>>
>> On Thu, Nov 1, 2012 at 3:35 PM, Shelan Perera <she...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> So shall we adhere to that method? i.e using fullstops instead of
>>> spaces. ? (I tested with fullstops and it worked)
>>>
>>> Thanks
>>>
>>>
>>> On Thu, Nov 1, 2012 at 9:37 AM, Evanthika Amarasiri 
>>> <evanth...@wso2.com>wrote:
>>>
>>>> Yes. We came across this issue while testing G-Reg 4.0.0 release and
>>>> then the solution given was to use fullstops instead of spaces. In fact, in
>>>> latest G-Reg packs, the default ServiceLifeCycle has a state in this
>>>> format.
>>>>
>>>> :
>>>> <state id="Production">
>>>>                     <datamodel>
>>>>                         <data name="transitionExecution">
>>>>                             <execution forEvent="Demote"
>>>> class="org.wso2.carbon.governance.registry.extensions.executors.DemoteActionExecutor">
>>>>                             </execution>
>>>>                             <execution forEvent="Publish"
>>>> class="org.wso2.carbon.governance.registry.extensions.executors.apistore.ApiStoreExecutor">
>>>>                             </execution>
>>>>                         </data>
>>>>                     </datamodel>
>>>>                     <transition event="Publish" target="
>>>> Published.to.APIStore"/>
>>>>                     <transition event="Demote" target="Testing"/>
>>>>                 </state>
>>>>                 <state id="Published.to.APIStore">
>>>>                 </state>
>>>> :
>>>>
>>>> Regards,
>>>> Evanthika
>>>>
>>>>
>>>> On Wed, Oct 31, 2012 at 11:36 PM, Janaka Ranabahu <jan...@wso2.com>wrote:
>>>>
>>>>> Hi Shelan,
>>>>>
>>>>> Did you try defining the state ID by replacing all the  whitespaces
>>>>> with '.' character.
>>>>>
>>>>> *Eg:- Ready For QA ==> Ready.For.QA*
>>>>>
>>>>> IIRC, it should show that correctly in the UI. Also IIRC, similar
>>>>> scenarios have been tested against lifecycles in past releases. Maybe QA
>>>>> folks can share more information on that.
>>>>>
>>>>> Thanks,
>>>>> Janaka
>>>>>
>>>>>
>>>>> On Wed, Oct 31, 2012 at 2:18 PM, Shelan Perera <she...@wso2.com>wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> For the issue [1] we cannot specify whitespaces in state ID. It is a
>>>>>> constraint added by SCXML and it gives an exception when it tries to 
>>>>>> parse.
>>>>>> According to this [2] release note they have mentioned
>>>>>> not to add white spaces in state IDs. A fix would be to add a
>>>>>> temporary element which will complaint with parsing and then again 
>>>>>> replace
>>>>>> it with white space. Is that approach clean enough to introduce?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>
>>>>>> [1] https://wso2.org/jira/browse/REGISTRY-1378
>>>>>>
>>>>>> [2]
>>>>>> http://svn.apache.org/repos/asf/commons/proper/scxml/tags/SCXML_0_7/RELEASE-NOTES.txt
>>>>>> --
>>>>>> *Shelan Perera*
>>>>>>
>>>>>> Software Engineer
>>>>>> **
>>>>>> *WSO2, Inc. : wso2.com*
>>>>>> lean.enterprise.middleware.
>>>>>>
>>>>>> *Home Page*  :    shelan.org
>>>>>> *Blog*             : blog.shelan.org
>>>>>> *Linked-i*n      :http://www.linkedin.com/pub/shelan-perera/a/194/465
>>>>>> *Twitter*         :https://twitter.com/#!/shelan
>>>>>>
>>>>>> *Mobile*          : +94 772 604 402
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Dev mailing list
>>>>>> Dev@wso2.org
>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Janaka Ranabahu
>>>>> Software Engineer
>>>>> WSO2 Inc.
>>>>>
>>>>> Mobile +94 718370861
>>>>> Email : jan...@wso2.com
>>>>> Blog : janakaranabahu.blogspot.com
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> *Shelan Perera*
>>>
>>> Software Engineer
>>> **
>>> *WSO2, Inc. : wso2.com*
>>> lean.enterprise.middleware.
>>>
>>> *Home Page*  :    shelan.org
>>> *Blog*             : blog.shelan.org
>>> *Linked-i*n      :http://www.linkedin.com/pub/shelan-perera/a/194/465
>>> *Twitter*         :https://twitter.com/#!/shelan
>>>
>>> *Mobile*          : +94 772 604 402
>>>
>>>
>>>
>>
>>
>> --
>> *Shelan Perera*
>>
>> Software Engineer
>> **
>> *WSO2, Inc. : wso2.com*
>> lean.enterprise.middleware.
>>
>> *Home Page*  :    shelan.org
>> *Blog*             : blog.shelan.org
>> *Linked-i*n      :http://www.linkedin.com/pub/shelan-perera/a/194/465
>> *Twitter*         :https://twitter.com/#!/shelan
>>
>> *Mobile*          : +94 772 604 402
>>
>>
>>
>
>
> --
> Janaka Ranabahu
> Software Engineer
> WSO2 Inc.
>
> Mobile +94 718370861
> Email : jan...@wso2.com
> Blog : janakaranabahu.blogspot.com
>
>


-- 
*Shelan Perera*

Software Engineer
**
*WSO2, Inc. : wso2.com*
lean.enterprise.middleware.

*Home Page*  :    shelan.org
*Blog*             : blog.shelan.org
*Linked-i*n      :http://www.linkedin.com/pub/shelan-perera/a/194/465
*Twitter*         :https://twitter.com/#!/shelan

*Mobile*          : +94 772 604 402
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to