Regarding abstrack class method names for AbstractModel,AbstractController,AbstractView

21 views
Skip to first unread message

Rajmahendra R

unread,
May 30, 2013, 1:38:25 AM5/30/13
to jrebirth-...@googlegroups.com
I see that there are some member methods of the classes AbstractModel,AbstractController,AbstractView names start with custom like


AbstractView
customInitializeComponents

AbstractModel
customInitialize
customInitializeInnerModels
customShowView
customHideView

AbstractController
customInitializeEventAdapters
customInitializeEventHandlers


Instead of using custom, we can use direct names like

AbstractView
initializeComponents

AbstractModel
initialize
initializeInnerModels
showView
hideView

AbstractController
initializeEventAdapters
initializeEventHandlers

Sebastien Bordes

unread,
May 30, 2013, 3:54:09 AM5/30/13
to jrebirth-...@googlegroups.com
You're right, it's not very convenient to use customXXXX method.

There is an UML class diagram that sum up UI package :

https://raw.github.com/JRebirth/JRebirth/master/org.jrebirth/core/src/main/uml/UI.png

(AbstractBaseModel is missing)

The reason was that the first abstract component of the hierarchy (for example AbstractView) required some code to prepare itself.

Each method is a lifecycle's phase that will handle:
_ jrebirth code
_user code

So I create intializeComponents and abstract customInitializeComponent, because overriding intializeComponents is a bad practice (super call can be forgotten breaking basic behaviours)

What do you think about renaming like this :

private final void initInternalView => jrebirth code (extension point to add code, AbstractView doesn't have any but model does https://github.com/JRebirth/JRebirth/blob/master/org.jrebirth/core/src/main/java/org/jrebirth/core/ui/AbstractModel.java)

protected abstract void initView => user code

What do you think about this ?
Let me know if you have a better naming idea

Seb

rajma...@gmail.com

unread,
May 30, 2013, 4:49:14 AM5/30/13
to jrebirth-...@googlegroups.com

initInternalView.... we can call it simply  initView   anyway developer is initializing the view he is working on so  no need to specifying Internal. initializeView also feels ok for me.   But this init prefix we can't use for  initHideView initShow view!  they will be hideView, showView as mentioned in my next point "do Methods"

I have one more.....

do Methods

In view, doXxxx methods sounds like doing something. Actually we are trying to write inside a action of the item so we can make it like Applet style of call  hide, reload, start etc.


Abstract Methods
I see there are some abstract methods in Abstract class. Its do sounds good, as the class is abstract. But it again raises a problem that, forced over-righting in sub class when we are really not going to use it then there are some methods developer need to have in there code!. Swing do have same issue, so later they started adopting Adapters (for interface) classes.

Any plan for removing this ?


--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes JRebirth Developers.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse jrebirth-develo...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
 
 



--
Thank you and regards,
Rajmahendra R Hegde (Raj)
Website:
http://www.twitter.com/rajonjava
http://www.jugchennai.in             
----------------------------------------------------------------------------------------------
"DREAM is not what you see in sleep;
is the thing which does not let you sleep" - APJ Abdul Kalam
Do the difficult things while they are easy and do the great things while they are small.
A journey of a thousand miles must begin with a single step. - Lao Tzu


Sebastien Bordes

unread,
May 30, 2013, 5:05:28 AM5/30/13
to jrebirth-...@googlegroups.com
==> The protected method taht use should implement will be as simple as possible : initView, but I need a name fr internal method that will call the user one and do some generics things

for hideView etc.. the same principle will be applied, user method will be hideView and internal method will be hideInternalView

the xxxInternalxxxx method could be named differently if you have a better idea.

But I want to keep these 2 levels : JRebirth default code (processed before) than user code.

==> doMethods will be renamed too

==> Abstract Methods allow to write high level components, for low level ones extends Default classes, ie: DefaultModel which override all required method without doing something
The counter part is that the user will have pmd error asking him to correct this error : http://checkstyle.sourceforge.net/config_design.html#DesignForExtension

Same principle is applied for event handler and adapters with Default Classes that extends Abstract ones avoiding to write useless empty methods.

This evening I will refactor some part that will be available into the snapshot version tomorrow.

Thank you for your useful feedbacks

Seb
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse jrebirth-developers+unsub...@googlegroups.com.

Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
 
 

Sebastien Bordes

unread,
May 30, 2013, 7:38:58 AM5/30/13
to jrebirth-...@googlegroups.com
I have refactored a lot of classes, I will push them tonight after some check on other projects.

What do you think about prefixing wave handler method by 'do' or something else concise ?

rajma...@gmail.com

unread,
May 30, 2013, 7:41:42 AM5/30/13
to jrebirth-...@googlegroups.com
I think we can make them plain  hide, reload,actionPlay


Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse jrebirth-develo...@googlegroups.com.

Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
 
 

Sebastien Bordes

unread,
May 30, 2013, 8:16:25 AM5/30/13
to jrebirth-...@googlegroups.com
I'm talking about wave handler method like this one :

https://raw.github.com/JRebirth/MasteringTables/master/org.jrebirth.demo.masteringtables/src/main/java/org/jrebirth/demo/masteringtables/ui/page/PageModel.java

showPage(Wave wave) will become doShowPage(Wave wave) to clearly mention that it's a wave callback

Other methods have been updated but not sitll pushed on Github

Seb
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse jrebirth-developers+unsubscribe...@googlegroups.com.

rajma...@gmail.com

unread,
May 30, 2013, 8:20:53 AM5/30/13
to jrebirth-...@googlegroups.com
showPage sounds ok for me.   It looks like standard term.


Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse jrebirth-develo...@googlegroups.com.

Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
 
 

Sebastien Bordes

unread,
May 30, 2013, 8:59:01 AM5/30/13
to jrebirth-...@googlegroups.com
showPage is not a basic model's method

It was called by reflection into JAT after having processed a Wave, this is the black magic side JRebirth.

Arguments of such method are managed with WaveItem and method with WaveTyp

So I want to tag all these custom methods.

To have the less impact possible I will parameterize this string, those who want no prefix will be able to do it by updating config file

Seb

Sebastien Bordes

unread,
May 31, 2013, 3:56:10 AM5/31/13
to jrebirth-...@googlegroups.com
new API has been pushed and is available in the latest snapshot (repo.jrebirth.org).

Enjoy it !
Reply all
Reply to author
Forward
0 new messages