Submitting to the core...
mP
and so on.. the big thing is deciding on the diff components we will
include... for this we need tests/demo pages so we can check all the
features and so on. It is for this reason i havent committed anything
to the sandbox otherwise there will be a lot of files in there when
perhaps only small chunks should be added to the sandbox in their
designated package once they have been accepted...
ash
could u pls consider the following:
1. branch from me
svn copy
https://gwt-commons-sandbox.googlecode.com/svn/branches/ash/gwt-commons/
https://gwt-commons-sandbox.googlecode.com/svn/branches/miroslav/gwt-commons/
-m "comment"
2. check out to create a wc of your private branch
3. take one category in rocket at a time (eg. dom)
you will likely need to educate us (me anyway) on many of the problems
that are being solved.
4. for each feature in rocket that must be migrated to commons
* add it to the appropriate namespace in the wc
* check whether the feature cross-cuts other assets already loaded in
commons
* refactor to fit the commons shape. that is refactor until that
feature is:
* consistent and integrated with the whole
for eg. consider jason's blindeffect & clamshellwidget:
before:
1.
http://gwt-commons-sandbox.googlecode.com/svn/tags/jason-gwt-commons-r28/src/org/gwtcommons/user/client/Blind.java
2.
http://gwt-commons-sandbox.googlecode.com/svn/tags/jason-gwt-commons-r28/src/org/gwtcommons/user/client/ui/ClamshellWidget.java
after:
1.
http://gwt-commons-sandbox.googlecode.com/svn/branches/ash/gwt-commons/src/org/gwtcommons/user/effects/BlindEffect.java
2.
http://gwt-commons-sandbox.googlecode.com/svn/branches/ash/gwt-commons/src/org/gwtcommons/user/widget/base/ClamshellWidget.java
clearly, it wasnt just the namespace that was refactored. it got
refactored to be part of the whole. this is challenging, it requires
that you understand and honour the principles, motivations and shape of
the whole while merging the part.
im here to help. i can collaborate with you on your private branch if u
wish.
rgds ash
http://www.gworks.com.au
mP
I think the sandbox idea is broken and not working. Just about all code
(ex widgets and visual stuff ) is missing unit tests ( eg
StringTokenizer, SimpleDateFormatter ). I believe it is wrong to accept
any such classes as it is impossible to enhance or fix due to the lack
of missing tests to verify things.
The widget stuff is better but I think we should be critical of what we
accept after we all review each n every bit that goes in. I know my
stuff has a lot of junk in it and I believe the same is true of other
libraries.
I think we should all be looking at each others stuff and accepting
following a review process. I am sure each and every thing that gets
accepted has issues and as such should be fixed before being
accepted...
GWT-WL
/////////////
org.gwtwidgets.client.ext
ExtDom relates to manipulating namespaces attached to an element. mP:
IGNORE who cares about namespaces when developing in GWT ?
org.gwtwidgets.client.style
BorderStyle contains constants relating to borders. mP: IGNORE
Orphaned code.
Color mP: IGNORE doesnt do anything
Coords mP: IGNORE only used by JsGraphicsPanel.
org.gwtwidgets.client.svg
mP: IGNORE Wouldnt be in core project due to svg dependency.
org.gwtwidgets.client.temp
TFlexTable mP: IGNORE i think the remove bug it addresses has been
fixd.
TFocusPanel mP: UNSURE
TGrid mP:UNSURE Has this been fixed in gwt ?
TMouseListenerCollection: mP: Purpose ?
org.gwtwidgets.client.ui.*
EditableLabel: mP: KEEP
FileUploadField: mP: IGNORE functionality exists in gwt.
ImageButton:
LightBox: mP: KEEP
PNGImage: mP: Keep - has this been fixed in gwt ?
ProgressBar: mP KEEP
ToggleButton: mP: Purpose ?
Calculator stuff -> move to a sub package.
CalcDisplayListener ? mP: put this in the same package as calculator
???
PopupCalcPanel mP:
org.gwtwidgets.client.ui.cal ( i would rename to calendar ).
* mP: Definitely need a calendar widget !
org.gwtwidgets.client.ui.gsearch
* mP: too specific not generic enuff i wouldnt include - perhaps
should appear in a project that includes widgets that interface with
specific websites
org.gwtwidgets.client.ui.pagination
* mP: whats the diff between this and rockets Pager widget ?
org.gwtwidgets.client.util.*
WindowUtils mP: shouldnt this be called URL
ArrayUtils mP: i think this already exists in rocket.util.*
CalcEngine: mP: Why is this not packaged with the other calc widget
stuff (org.gwtwidgets.client.ui.*)
Cookie,CookieUtils
NumberFormat: Unit tests ?
SimpleDateFormat Unit tests ?
org.gwtwidgets.client.wrap.*
Callback mP: similar to DeferredCommand
JsCalendar: mP: needs a better name like CalendarWidget
JsGraphicsPanel: mP: needs a better name w/out the "Js" maybe somethin
glike CanvasPanel
WBuilder: mP: creates widget view of elements within the dom.
mP
On Nov 28, 9:12 pm, "ash" <ash...@gmail.com> wrote:
> mate, i just did an svn update, rocket has grown!
>
> could u pls consider the following:
> 1. branch from me
> svn copyhttps://gwt-commons-sandbox.googlecode.com/svn/branches/ash/gwt-commons/https://gwt-commons-sandbox.googlecode.com/svn/branches/miroslav/gwt-...
> -m "comment"
>
> 2. check out to create a wc of your private branch
>
> 3. take one category in rocket at a time (eg. dom)
> you will likely need to educate us (me anyway) on many of the problems
> that are being solved.
>
> 4. for each feature in rocket that must be migrated to commons
> * add it to the appropriate namespace in the wc
> * check whether the feature cross-cuts other assets already loaded in
> commons
> * refactor to fit the commons shape. that is refactor until that
> feature is:
> * consistent and integrated with the whole
>
> for eg. consider jason's blindeffect & clamshellwidget:
> before:
> 1.http://gwt-commons-sandbox.googlecode.com/svn/tags/jason-gwt-commons-...
> 2.http://gwt-commons-sandbox.googlecode.com/svn/tags/jason-gwt-commons-...
>
> after:
> 1.http://gwt-commons-sandbox.googlecode.com/svn/branches/ash/gwt-common...
> 2.http://gwt-commons-sandbox.googlecode.com/svn/branches/ash/gwt-common...
mP
I also had a look at the WLS SpringController component. I thought it
took care of the marshalling and dispatching of rpc requests from
something like a gwt app. I thought it took care of providing the glue
between an impl of a service (less RemoteService) n the GWT client.
>From what I can it doesnt do that - i am not exactly sure of what it
does. I would definitely think we should have some serverside component
that does what I have just describe as dependencies on the GWT
RemoteServiceServlet is not a good thing...
I will deffinitely put it on my list of things to do...
mP
> > svn copyhttps://gwt-commons-sandbox.googlecode.com/svn/branches/ash/gwt-commo......
mP
////////////////////
Write a servlet wich provides the glue between gwt clients and java
server side services. The interface does not have any direct
dependencies on RemoteServiceServlet.
1) unmarshal
2) locate bean
3) invoke service method
4) marshal object back.
servlet needs a map which maps service to bean impl.
On Dec 1, 7:04 pm, "mP" <miroslav.poko...@gmail.com> wrote:
> Ash:
>
> I also had a look at the WLS SpringController component. I thought it
> took care of the marshalling and dispatching of rpc requests from
> something like a gwt app. I thought it took care of providing the glue
> between an impl of a service (less RemoteService) n the GWT client.>From what I can it doesnt do that - i am not exactly sure of what itdoes. I would definitely think we should have some serverside component
ash
> I think the sandbox idea is broken and not working. Just about all code
to commit time.
both george and rob indicated a level of urgency to get a release out
by year end and i tried to validate that with others regarding our
priorities (see thread).
my typical approach to designing and building an api/library/framework
was over shadowed with time to market pressures. therefore i stopped at
principles in terms of following a process. however, for me this was
less of an issue if i influenced its initial shape with much of the
thinking from gemsv2. therefore to get the ball rolling i created the
sandbox with the gems migration to commons.
the individual cm branches in the sandbox is the path of least
resistance. it lets that contributor share thinking and merge concepts
with others as they see fit. it lets the ball start rolling. eventually
we hit integration & consistency issues as i did with andres sandbox
and rocket assets. hence, i needed to ping u to work out how to take
those units forward.
> (ex widgets and visual stuff ) is missing unit tests ( eg
> StringTokenizer, SimpleDateFormatter ). I believe it is wrong to accept
> any such classes as it is impossible to enhance or fix due to the lack
> of missing tests to verify things.
if u are motivated to do so, then please commit such test cases and
build up a regression test-suite. then incorporate the test-suite into
the build process and ensure that all committers verify success before
committing code.
as i have indicated to u in the past, im not a tdd guy and my past
experiences yielded poor roi on such approaches. i get greater value
out of demo pages and reference applications.
> The widget stuff is better but I think we should be critical of what we
> accept after we all review each n every bit that goes in. I know my
> stuff has a lot of junk in it and I believe the same is true of other
> libraries.
sure, then start with mine. you have:
* as many demo pages that i have had time to commit over this period
* the code in the sandbox and
* the petstore example that works against that code base
the reference application (ie. petstore) helps us remain contextual and
concrete.
by all means, go ahead and refactor the hell out of it, add test-cases,
build a regression suite. but ensure that the demos and reference
example still function.
> I think we should all be looking at each others stuff and accepting
> following a review process. I am sure each and every thing that gets
> accepted has issues and as such should be fixed before being
> accepted...
this will indeed improve the quality and consisteny - a good thing! but
u can kiss the end of year release goodbye.
ok, before i get into the next bit, i have to confess, i have not used
rocket or gwl in any application. i have used and am fully committed to
using georges SL library. i know georges library initimately and have
made several extensions. therefore, i have merged georges SL into my
sandbox.
rgds ash
http://www.gworks.com.au
ash
shipped inside gwl
i suggest u take a look at:
1.
http://gwt-commons-sandbox.googlecode.com/svn/branches/ash/gwt-commons/demo/org/gwtcommons/demo/feature/remoting/
2.
http://gwt-commons-sandbox.googlecode.com/svn/branches/ash/gwt-commons/demo/org/gwtcommons/demo/feature/remoting/WEB-INF/GWTSpring-servlet.xml
3.
http://gwt-commons-sandbox.googlecode.com/svn/branches/ash/gwt-commons/demo/org/gwtcommons/demo/feature/remoting/server/CalculateRpcImpl.java
if you want to a see a more realistic example with the rpc impls
calling the petstore facaded wrapped in a transaction then look at:
4.
http://gwt-commons-sandbox.googlecode.com/svn/branches/ash/gwt-petstore/src/au/com/gworks/gwt/petstore/server/ShoppingRpcControllerImpl.java
rgds ash
http://www.gworks.com.au
Robert Hanson
questions that I can quickly answer...
> ExtDom relates to manipulating namespaces attached
> to an element. mP: IGNORE who cares about namespaces
> when developing in GWT ?
This is needed for the SVG stuff in the GWT-WL.
> TFocusPanel mP: UNSURE
Reports x/y coords relative to the top-left of the widget for mouse
events. I saw this as a GWT bug, but maybe I just didn't understand
the coordinates the FocusPanel was returning.
> TGrid mP:UNSURE Has this been fixed in gwt ?
I'm not sure if it was fixed.
> TMouseListenerCollection: mP: Purpose ?
This goes with TFocusPanel.
> ImageButton:
This uses a lot of the style classes that you mentioned. It isn't
bad, but I would probably rethink the implementation.
> PNGImage: mP: Keep - has this been fixed in gwt ?
I don't think that it was fixed... mostly because it isn't a GWT bug,
it is an IE6 bug.
> ToggleButton: mP: Purpose ?
Toggles between two states. If it was kept, we might want to revisit
the implementation.
> JsCalendar: mP: needs a better name like CalendarWidget
The name is the same of the JS library that it wraps.
> JsGraphicsPanel: mP: needs a better name w/out the "Js"
> maybe something like CanvasPanel
The name is the same of the JS library that it wraps.
Rob