Future addButton() syntax – I need your suggestions

Monday, April 19th, 2010|Brainstorming, Version 3|by Romans

I’d like to hear your opinion about some suggestions towards button implementation

Currently there are 2 versions running around:

1) $form->addButton()->redirect(‘/’)  - in this one form’s addButton is returning $js(‘click’)->univ() of the button. This is backward compatible version and seriously, why would we need to do anything with button but redirect.

2) $form->addButton()->js(‘click’)->univ()->redirect(‘/’) – here addButton returns “View_Button” object. The benefit is that you can do certain things with is such as addLabel or setStyle(), which will affect how button looks. Also instead of just clicks you can use other events, such as mouse-over etc. This is more standard-compliant version IMHO

I’d like to hear from you, which implementation of Form::addButton and Grid::addButton you prefer? Also to help with compatibility Button::redirect() implemented through #2 will allow for syntax of #1 but this is for obsolete syntax and should be avoided.


Svetlozar Kondakov
Posted April 19, 20105:52 pm

I also think #2 is more standard implementation … and where we maybe wont do more than just redirect with a button as stated in #1, it is not the default logical atk way e.g. to return added object after $this->add.

I think its worth writhing the extra chars “->js(‘click’)->univ()” in #2 in order to keep the flexibility of this option

Posted April 19, 20106:52 pm

btw – this is on a roadmap for atk4, but i was thinking to introduce a simple concept. Any function starting with “add” would return a new object. add() is like that but addField, addColumn etc – they would all return new object. Problem is – they can’t be chained anymore, so i wonder if it’s good.

also all functions which do not start with add and get will return $this.