PDA

View Full Version : [CLOSED]panel / formPanel: buttons cannot be retrieved anymore



jan.harmsen
2 Mar 2011, 1:28 AM
In ExtJS 4, buttons defined in config via buttons[] Array cannot be retrieved anymore, because there is no method for easily accessing buttons.

In ExtJS 3, buttons defined in config-section via buttons[] Array


buttons: [
{ itemId: 'btnSave',
text: 'itemId = btnSave'
},
{ itemId: 'btnCancel',
text: 'itemId = btnCancel'
}
]

could be retrieved easily via:


mypanel.getFooterToolbar().getComponent('btnSave')


In ExtJS 4, there is no FooterToolbar anymore and thus no 'getFooterToolbar()'.
That means there is no method to retrieve buttons defined in config section.

Please provide a method for easily accessing buttons defined in config section.
Since handlers not making use of anonymous functions need to be assigned to buttons in initComponent(), it is necessary to have access to the buttons defined in the config section.

Thanks!

evant
2 Mar 2011, 1:37 AM
This isn't a bug. tbar/fbar/bbar Have been deprecated in favour of dockedItems:



Ext.require('*');

Ext.onReady(function(){
new Ext.Panel({
width: 400,
height: 400,
renderTo: document.body,
dockedItems: [{
dock: 'bottom',
xtype: 'toolbar',
ui: 'footer',
items: ['->', {
text: 'I am a button'
}]
}]
});
});


Also, the buttons config is available for backwards compat:



Ext.require('*');

Ext.onReady(function(){
new Ext.Panel({
width: 400,
height: 400,
renderTo: document.body,
buttons: [{
text: 'Foo'
}]
});
});

jan.harmsen
2 Mar 2011, 2:10 AM
I think it is a little bit too early to mark this one as closed:

When comparing the lines of code in your two examples, I have to say that the last example using config-section buttons[] is much more readable (less code) and applies to probably 90 % of all FormPanels. At least I have not seen too many forms where the save / cancel buttons where at the top or on the left or right.

In a form, buttons are typically at the bottom, like it used to be the default with Ext JS 3.

While I really do appreciate the flexibility that comes with Ext JS 4 (being able to position top, left, right, bottom), I think it is a step backwards to now always have to use this explicit way of configuring buttons for FormPanels (because otherwise buttons cannot be retrieved easily since there is no method available).

Why is it not possible to provide a method for accessing buttons defined in config-section of a form panel?

If buttons[] definition in config-section is deprecated, it needs to be marked so. The current Ext JS 4 documentation still has a long way to go, there is a lot of room for improvement. (sorry for saying that, but it's frustrating as hell to work with the current docs)

If buttons[] definition in config-section is deprecated, Ext JS 4 does not support the DRY-principle (Don't Repeat Yourself), because it forces developers for 90% of all cases (buttons at the bottom of the form) to write the same code (toolbar definition) again and again.

Does it really make sense to deprecate the buttons[] config section and not to provide a method for easily accessing buttons in bottom toolbar?

Thanks (I appreciate all the hard work you are putting into Ext JS 4)

jan.harmsen
2 Mar 2011, 2:42 AM
well, looks like retrieving a button defined in buttons[] is relatively easy with the new Ext JS 4 Ext.ComponentQuery

http://dev.sencha.com/deploy/ext-4.0-pr2/docs/api/Ext.ComponentQuery.html

as pointed out here: http://www.sencha.com/forum/showthread.php?124238-Ref-Property

So to address a button defined in


buttons: [
{ itemId: 'btnSave',
text: 'Save'
},
{ itemId: 'btnCancel',
text: 'Cancel'
}
]



one can use

myComponent.query('#btnSave')

which returns an Array with found components with itemId 'btnSave', i.e. the button reference will be
myComponent.query('#btnSave')[0].

While it is not ideal I can live with that.

This still leaves the question, whether it makes sense to mark buttons[] config section as deprecated.

evant
2 Mar 2011, 3:40 AM
// Selects a single item
panel.down('#foo');

// or
var toolbar= panel.getDockedItems().itemAt(index);


It will be added to the upgrade guide that it's been deprecated.

I don't really agree that this is any violation of the DRY principle. The docked items can apply to ~any~ panel, not just a form panel. You're isolating a very specific case. Writing:



buttons: [{
text: 'Foo'
}]


vs



dockedItems: [{
dock: 'bottom',
xtype: 'toolbar',
items: [{
text: 'Foo'
}]
}]


Is only a couple of lines more and infinitely more flexible. It also gives greater granularity in how the toolbar is laid out which was much more difficult previously.

jan.harmsen
2 Mar 2011, 6:08 AM
I doubt that I am isolating a very specific case.
When it comes to working with forms, the 90% case in a form is: buttons at the bottom.

So 'flexibility' in this case is NOT what a form developer needs.
Rather more a convenient way to

define buttons
access buttons for attaching handlers when the component gets initialized

is required.

With the buttons[] config being deprecated in Ext JS 4, I now need to build a solution myself since the example you provided makes it obvious that it's not easy to identify buttons immediately, i.e. at first sight when looking at the code.

It's not a question of agreeing or disagreeing, it's just a fact that


buttons: [
{ itemId: 'btnSave',
text: 'Save'
},
{ itemId: 'btnCancel',
text: 'Cancel'
}
]


is self-explanatory (shows at first sight what the buttons are) and needs little code, while


dockedItems: [{
dock: 'bottom',
xtype: 'toolbar',
itemId: 'button_toolbar',
items: [
{
itemId: 'btnSave',
text: 'Save'
},
{
itemId: 'btnCancel',
text: 'Cancel'
}
]
}]


is not only more code but also less self-explanatory.

I appreciate flexibility, but when it comes to working with forms I dislike always having to build a workaround for the 90% case only to get flexibility for the 10% where it's needed.

A good framework from my point of view is one, that makes it easy / convenient to solve the 90% case. Currently Ext JS 4 is flexible, but it does not make it easy / convenient to solve the 90% case when it comes to working with forms (and having buttons at the bottom).

Just my 5 cents....

Seana
2 Mar 2011, 7:09 AM
I doubt that I am isolating a very specific case.
When it comes to working with forms, the 90% case in a form is: buttons at the bottom.

So 'flexibility' in this case is NOT what a form developer needs.
Rather more a convenient way to

define buttons
access buttons for attaching handlers when the component gets initialized

is required.

With the buttons[] config being deprecated in Ext JS 4, I now need to build a solution myself since the example you provided makes it obvious that it's not easy to identify buttons immediately, i.e. at first sight when looking at the code.

It's not a question of agreeing or disagreeing, it's just a fact that


buttons: [
{ itemId: 'btnSave',
text: 'Save'
},
{ itemId: 'btnCancel',
text: 'Cancel'
}
]


is self-explanatory (shows at first sight what the buttons are) and needs little code, while


dockedItems: [{
dock: 'bottom',
xtype: 'toolbar',
itemId: 'button_toolbar',
items: [
{
itemId: 'btnSave',
text: 'Save'
},
{
itemId: 'btnCancel',
text: 'Cancel'
}
]
}]


is not only more code but also less self-explanatory.

I appreciate flexibility, but when it comes to working with forms I dislike always having to build a workaround for the 90% case only to get flexibility for the 10% where it's needed.

A good framework from my point of view is one, that makes it easy / convenient to solve the 90% case. Currently Ext JS 4 is flexible, but it does not make it easy / convenient to solve the 90% case when it comes to working with forms (and having buttons at the bottom).

Just my 5 cents....

I'm going to disagree with you on a couple of points.

#1) When working with forms, in your usage it maybe 90% you need Buttons at the bottom, However in my current project all of the form submit/clear/cancel buttons are on a Toolbar at the top of the panel because that's where they "flow" in the layout. So in my case the 3.x buttons: [] style is 100% useless and this goes for the last two projects that I've worked on.

#2) On the explanation front: I'm looking forward to the dockedItems config as it is far more versatile, and with the exception of coming from a "purely Previous ExtJS background" is far more explanatory than buttons:[] which tells you only that they are buttons, not that they are docked, nor where they reside in the layout.

The point that I'm looking to make here is that while in your context these uses maybe the 90% case they aren't necessarily the global 90% let alone the global majority. Should it really be that much of an issue, a simple subclassing of Panel that handles a buttons:[] style config array and defines the expected use for getFooterToolbar() should be simple, very little time to write and that class is instantly available to you 100% of the time to use.

jan.harmsen
2 Mar 2011, 7:59 AM
Nothing wrong with disagreeing :-)

But let's look at some facts:


In the western world, text is written from left to right and from top to bottom, like this thread / post.
Due to this, in the western world forms get filled out from top to bottom.
Unless screen size is restricted, it is thus natural for users filling out a form to find buttons for saving (submitting) / canceling right at the bottom of the form


Thus this is not an isolated case but applies to probably more than 90% of all forms on the web being viewed by PCs / Macs (note, I'm excluding phones here since phones have restricted screen space). In the western world it is just a common best practice to place buttons for submitting / canceling a form at the bottom of the form, based on the way people work.

Of course a designer / developer is free to put the buttons wherever he/she wants: At the top or on the left or on the right. And there are cases where this makes sense. But for the western world and PC / Mac clients, usability principles recommend to place buttons where a user filling out a form expects buttons -- and this is at the bottom due to the workflow described above. Period.

Last but not least:
Yes, you are right.
It is a piece of cake of subclassing FormPanel and making it the way I need it.
And there will be many others subclassing FormPanel, now that buttons[] is gone. That's the way the cookie crumbles ;-)

Condor
2 Mar 2011, 8:15 AM
This is something for the legacy .js file:
It should add the getTopToolbar(), getBottomToolbar() and getFooterToolbar() methods and the 'tbar', 'bbar', 'fbar' and 'buttons' properties to Ext.panel.Panel.

Seana
2 Mar 2011, 8:33 AM
Unless screen size is restricted, it is thus natural for users filling out a form to find buttons for saving (submitting) / canceling right at the bottom of the form



When using ExtJS I always have restricted screen size, because I'm building an application not a web page, while for strait web pages I whole heartedly agree with your flow.

ExtJS is an Application Framework, and if MFC ever taught me anything, Frameworks always have places that you wish you could change 'em ;)

And I agree, there's nothing wrong with disagreeing :)

mdavis6890
2 Mar 2011, 8:33 AM
I'd like to make a brief comment on flexibility and creativity:

One reason why people usually put the buttons at the bottom of the form might be that putting them anywhere else is a pain in the neck.

More flexibility allows for more creativity in the solution. I think now you'll see people putting buttons in lots of different orientations.

Michael

jan.harmsen
2 Mar 2011, 8:51 AM
I'd like to make a brief comment on flexibility and creativity:

More flexibility allows for more creativity in the solution. I think now you'll see people putting buttons in lots of different orientations.

Michael

And in many cases this will rather be a problem than a solution, resulting in poor usability.
Form follows function and creativity needs to follow usability.

The world is full of software with bad usability. Flexibility to put buttons anywhere won't change that.

Unless one follows a ui styleguide and ui prototype which is strictly based on usability principles, this kind of 'creativity' will lead to frustrated users who do not find what they are looking for.

I highly recommend having a look at the usability standard DIN EN ISO 9241-110 http://en.wikipedia.org/wiki/ISO_9241

Seana
2 Mar 2011, 9:22 AM
And in many cases this will rather be a problem than a solution, resulting in poor usability.
Form follows function and creativity needs to follow usability.

The world is full of software with bad usability. Flexibility to put buttons anywhere won't change that.

Unless one follows a ui styleguide and ui prototype which is strictly based on usability principles, this kind of 'creativity' will lead to frustrated users who do not find what they are looking for.

I highly recommend having a look at the usability standard DIN EN ISO 9241-110 http://en.wikipedia.org/wiki/ISO_9241

Refereeing to 9241-17, the standard was created near mainstream adoption of "windowing" principals in software interface design. Prior to that there was another complete set of specifications that dealt specifically with the "standard" ways to lay out software in a single, screened environment. You can with-in the realms of adhering to such standards still design and innovate, should that not be the case I'd still be doing my primary web development on Windows 3.11, a Shiva TCP/IP Dial up stack, and Mosaic.

Standards Give you a platform on which to innovate, not a prison to live with-in and look exactly like every other inmate.

I can adhere to "best practices" with a config that places my submit/cancel buttons in a Dock where dock: 'right' and the Buttons are aligned to the Bottom of the Dock.

I can adhere to "best practices" with a config that places my submit/cancel buttons in the form layout itself at the bottom right hand side under the last field.

I can adhere to "best practices" with a config that places my submit/cancel buttons in a Dock where dock: 'bottom' and the Buttons are aligned to the right of the Dock.

I'm sure there are other extremely valid and plausible layout options that fit in a plethora of possible designs that all adhere to ISO-9241, or other standards should those be more applicable in usage.

The point here isn't that there are standards that dictate usability. The point here is that there are multitudes of possible applications that can and will be made using ExtJS 4.0. While your applications may always follow the same form/function there are other customers of the Product that could need explicitly different functionality. As it stands now in ExtJS 3.x if you wanted to have a "dock" on the right or left facilitating buttons you have a LOT of extra code that you have to maintain in conjunction with not only your applications code, but every update to the under lying Library.

I would say that the benefits to the current "ExtJS 4.0 Way" of handling this from a Library design standpoint FAR out way the fact that to get the previous functionality developers will have to add 4/5 more config options to their code. and change how they query those objects. This is a prime example of the maturity of ExtJS 4.0 in comparison to 3.x, they (Sencha) have gone beyond offering just the "status quo" and allow the developer the freedom to be innovative.

jan.harmsen
2 Mar 2011, 11:56 PM
@forum admins: please move from 'Bugs' to 'Help' thread, thanks!
(Now that it's official that buttons[] is gone aka 'it's a feature not a bug' I don't want to clutter up the 'Bugs' thread.


@senea: a good standard is like a good book: valid for many years, if not timeless.
Technology evolves fast, human behaviour / mankind doesn't
- though it seems to me some people already have a programmable chip where their brain used to be ;-)
By the way, I was referring to ISO 9241-110 not 9241-17, though the latter one is still valid as well.


Self-explanatoriness is an important thing since it correlates with the learning curve:
If something is self-explanatory you actually don't have to learn. If something is not self-explanatory, one has to learn and that's exactly the problem.

Compare example 1


buttons: [
{itemId: 'btnSave',
text: 'Save'},
{itemId: 'btnCancel',
text: 'Cancel'}
],

buttonLocation: {
position: 'bottom',
align: 'center'
}


with example 2:


dockedItems: [{
xtype: 'toolbar',
ui: 'footer',
dock: 'bottom',
layout: {
type: 'hbox',
pack: 'center'
},
items: [
{itemId: 'btnSave',
text: 'Save'},
{itemId: 'btnCancel',
text: 'Cancel'}
]
}]


Example 1 is much more self-explanatory than example 2.
Take somebody unfamiliar with ExtJS and ask where the buttons are defined and how to change button location to bottom right.
Code based on example 1 will make it easy for anybody to answer this question. Anybody producing code based on example 2 should realize that this is not a good idea.

And just by coincidence here is proof of what I am talking about:
http://www.sencha.com/forum/showthread.php?125623-FormPanel-buttonAlign-not-working
I quote:

One of the things that I have been trying to get to work for one entire day is the buttonAlign in the FormPanel. I have a FormPanel that I would like to have the buttons centered.

A typical answer by a developer might be to call this guy inexperienced / not reading the docs - source code / whatever.
That does not help. There is somebody having a problem and the problem exists ONLY because the code is not self-explanatory.

Location of buttons in a form usually does not change within an application. Thus it makes sense to define a 'standard' location which can be overwritten if desired.

Not so with Ext JS 4, one now has to either subclass or explicitly define the location
From my point of view subclassing in the line of abstract classes (see http://blog.extjs.eu/know-how/factory-functions-in-ext-extensions/) is the only way to go, i.e. additional initial effort, which will pay off big time later.

Is Ext JS 4 a good JavaScript application framework? YO.
Y for yes because it works across browsers, is based on a solid foundation and has many quite mature ui widgets and good support for data exchange / storage / theming.
O for no because it lacks clarity in many areas (resulting in a flat learning curve) and currently does not provide integral support for features like breadcrumbs, i18n/l10n which are required by any bigger application.

Last but not least: I promise that this was my last posting in this thread for a while, I've got some work to do ;-)

Seana
3 Mar 2011, 6:58 AM
@forum admins: please move from 'Bugs' to 'Help' thread, thanks!
(Now that it's official that buttons[] is gone aka 'it's a feature not a bug' I don't want to clutter up the 'Bugs' thread.


@senea: a good standard is like a good book: valid for many years, if not timeless.
Technology evolves fast, human behaviour / mankind doesn't
- though it seems to me some people already have a programmable chip where their brain used to be ;-)
By the way, I was referring to ISO 9241-110 not 9241-17, though the latter one is still valid as well.


Self-explanatoriness is an important thing since it correlates with the learning curve:
If something is self-explanatory you actually don't have to learn. If something is not self-explanatory, one has to learn and that's exactly the problem.

Compare example 1


buttons: [
{itemId: 'btnSave',
text: 'Save'},
{itemId: 'btnCancel',
text: 'Cancel'}
],

buttonLocation: {
position: 'bottom',
align: 'center'
}


with example 2:


dockedItems: [{
xtype: 'toolbar',
ui: 'footer',
dock: 'bottom',
layout: {
type: 'hbox',
pack: 'center'
},
items: [
{itemId: 'btnSave',
text: 'Save'},
{itemId: 'btnCancel',
text: 'Cancel'}
]
}]


Example 1 is much more self-explanatory than example 2.
Take somebody unfamiliar with ExtJS and ask where the buttons are defined and how to change button location to bottom right.
Code based on example 1 will make it easy for anybody to answer this question. Anybody producing code based on example 2 should realize that this is not a good idea.

And just by coincidence here is proof of what I am talking about:
http://www.sencha.com/forum/showthread.php?125623-FormPanel-buttonAlign-not-working
I quote:


A typical answer by a developer might be to call this guy inexperienced / not reading the docs - source code / whatever.
That does not help. There is somebody having a problem and the problem exists ONLY because the code is not self-explanatory.

Location of buttons in a form usually does not change within an application. Thus it makes sense to define a 'standard' location which can be overwritten if desired.

Not so with Ext JS 4, one now has to either subclass or explicitly define the location
From my point of view subclassing in the line of abstract classes (see http://blog.extjs.eu/know-how/factory-functions-in-ext-extensions/) is the only way to go, i.e. additional initial effort, which will pay off big time later.

Is Ext JS 4 a good JavaScript application framework? YO.
Y for yes because it works across browsers, is based on a solid foundation and has many quite mature ui widgets and good support for data exchange / storage / theming.
O for no because it lacks clarity in many areas (resulting in a flat learning curve) and currently does not provide integral support for features like breadcrumbs, i18n/l10n which are required by any bigger application.

Last but not least: I promise that this was my last posting in this thread for a while, I've got some work to do ;-)

First off: I'm sorry your are promising that to be your last post, I've thus far quite enjoyed the discussion. As a developer you can only grow from a well organized debate :D

Now on to the topic at hand ;)

On the Standards issue I agree with you, from a user stand point. From a developers stand point your argument is a bit more convoluted. You are trying to argue that because the standard that you are conforming to dictates that buttons are located at a particular location for your users that a general purpose library should cater to only a very specific use case, and not consider other potential use cases that could be far more prevalent in applications other than your own.

With in the context of an Application I still maintain that "buttons" is to ambiguous, and your example #1 is flawed in that there is no buttonLocation config property to begin with and thus isn't really a valid argument for reverting to the previous state. To take this even a step further, I would argue that if you are worried about another developer having issue picking up your ExtJS 4 based code that you modify your #2 example to some thing like...



dockedItems: [{
xtype: 'toolbar',
ui: 'footer',
dock: 'bottom',
layout: {
type: 'hbox',
pack: 'center'
},
items: [
{xtype: 'button',
itemId: 'btnSave',
text: 'Save'},
{xtype: 'button',
itemId: 'btnCancel',
text: 'Cancel'}
]
}


At that point I would argue that the example is every bit as understandable as your Example #1

On the point of someone asking for help in the linked thread, there isn't even a "buttonAlign" config in the Ext.form.FormPanel(ExtJS 4.0) Documents, so that form post goes further as an example of my point that there is a Learning curve associated to "over coming" your previously conceived ExtJS 3.X notions. Not that the code base is counter-intuitive. Above and beyond that there are always going to be people that come to a forum when they don't under stand the documentation, no mater the quality of that documentation. I'm not one to say that's a bad thing, I've done it too.

Should the Buttons config truly be needed it will be still available via the compatibility layer that's (supposed to be) forth coming.