Hi Azeez,

Due to the release work on 3.0.0 and cloud GS, I could not adopt the major
changes we have discussed. I will be able to complete the rest of tasks by
next week. Completed tasks are as follows.

On Wed, Mar 24, 2010 at 5:39 PM, Ruchira Wageesha <[email protected]> wrote:

>
>    - Need proper documentation for creating and configuring dashboard.xml
>
>
>    - Structure of dashboard.xml should be easily understandable/readable
>
>
>    - Using JSON format for dashboard.xml would not be appropriate, a
>       proper xml structure should be there
>       - Anyway, using JSON for gadgets and xml for the layout might be
>       appropriate
>
> We are planing to replace the entire dashboard.xml model with our coming up
template system. Hence did not invest much time on this, however I will
write a wiki page, for the use of previous dashboard versions.

>
>    - Get rid of common bundle
>
> Since this is a major change in dashboard components we postponed this till
the release is done. I will incorporate these changes by next week.

>
>    - Need to check whether debug is enabled before logging
>
> Done.

>
>    - Exceptions should be properly handled
>
>
>    -  Should be able to quickly identify any error with stacktrace and
>       logs
>
> Done, all exceptions are logged with a message and the stack-trace.

>
>    -  Logging message should be added to the exception
>
> Done.

>
>    -  Exceptions shouldn't be swallowed, if not in any case, should be
>       properly commented the reason
>
> Done.

>
>    -  Throwing AxisFault with an error code/message and handing it
>       accordingly
>
> Need to complete, since we had to change most of the dashboard server and
UI bundles, to handle axis faults from the FE, we postponed it till the
release work is over.

>
>    - Need to think about distributed nature
>
>
>    - Availability of resources should be checked properly before using
>       them.
>
> Done.

>
>    - i.e. we should check whether the registry is available and failure
>       conditions should be handled
>
> Done.

>
>    - Add a mothod into carbon utils to get backend http port
>
>
>
>
>    - Proper coding to avoid unnecessary memory usage.
>
>
>    - e.g. defining error message separatly and passing it into the debug()
>       method
>
> Done.

>
>    - Using readable variable names
>
>
>    - e.g. boolean variable names should start with is, "isNewUser"
>
> Done.

>
>    - Using primitive data types where possible as object initiation wastes
>    more resources
>
> Done.

>
>    - Remove unnecessary parenthesis
>
> Done.

>
>    - Extract repetitive codes and use methods instead
>
>
>    - both in Java and Javascript
>
> Done.

>
>    - Remove redundant varialbes
>
> Done.

>
>    - Comments should be added
>
>
>    - At Java class declaration(describing the class)
>       - In Javascripts codes
>
> Done.

>
>    - Proper coding convension should be followed across the plaltform for
>    Javascripts
>
> I reviewed few coding standards on JS, I will send a mail regarding that to
@Archtecture ASAP

>
>
>
>    - Get rid of using CDATA in gadgets as it is difficult to validate the
>    JS code
>
>
>    - Separate JS code into files and use references to those files
>       instead
>
> This should be practised by all gadget developers, in referent product
teams. Gadgets in GS are quite primitives and does not need external JS
links.

>
> *Proposed Features*
>
>    - User specific gadget repo (i.e. giving users a registry space to
>    store gadgets) and gadget sharing
>
>
> _______________________________________________
> Carbon-dev mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>
>

Thanks & Regards
-- 
Nuwan Bandara
Software Engineer
WSO2 Inc. | http://wso2.com
lean . enterprise . middleware

http://www.nuwanbando.com
_______________________________________________
Carbon-dev mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Reply via email to