PDA

View Full Version : No more Ext.StatusBar ?



phpcs
8 May 2009, 12:40 AM
I've been porting my ex apps to extjs3, ( and having lots of problem with that new encapsulation model )
However Y there's no more any statusBar in Ext? what to use instead?

evant
8 May 2009, 12:48 AM
StatusBar was removed. There's no equivalent included in the core. Your best bet is to port the StatusBar from 2.x over to 3.x code. It shouldn't be hard.

phpcs
8 May 2009, 1:03 AM
Ok, I can see that, but I asked why?

mschwartz
8 May 2009, 5:13 AM
Ext.ux.StatusBar for 3.0:

http://extjs.com/forum/showthread.php?t=65632

aurelien
19 May 2009, 6:21 AM
I agree with phpcs, WHY was the statusbar removed? It seems to me a must have widget!

crysfel
19 May 2009, 7:35 AM
According with the development team:


I've chatted with the guys, it's been removed on purpose, basically it didn't provide (much) extra over the toolbar to warrant being it's own component.

http://extjs.com/forum/showthread.php?p=300025#post300025

mschwartz
19 May 2009, 9:01 AM
I disagree that statusbar provides little more than toolbar.

It provides for display of status text, animation of status text messages, styling (icon) of the status text messages, and animated loading indicator. At least.

It's as different from toolbar as pagingtoolbar.

$.02
B)

19 May 2009, 9:30 AM
I agree with phpcs, WHY was the statusbar removed? It seems to me a must have widget!

I disagree with this comment. It is *not* a must-have widget. It is really easy to create and was not really used by many people.

DigitalSkyline
19 May 2009, 2:40 PM
I had one coded actually, prior to it being included in the library... so I switched to it.

It may be easy to recreate/port/code etc., but how does one conclude it was not used by many people? I don't really care if its included or not, but probably would have been a good idea to include it as an extra for those who want to upgrade without having to reinvent the wheel.

aurelien
25 May 2009, 1:02 AM
Hello all -

Thanks for your responses! And sorry for the delay it was a very long week-end in France...

Jay, I disagree too. But by saying "it seems to me", I think no one - even you - can say it is needed or not. The discussion is not really if the status bar is needed or not (even if for my use, 9 applications on 10 has a status bar, perhaps a French behaviour? ;)).

Excluding the status bar from the framework break the compatibility between 2.x and 3.x. I agree that it is not difficult to port it ourself but I think there is so many other part easy to port... The reason of this exclusion does'nt seem to me obvious or justified.

Cheers

dawesi
25 May 2009, 1:18 AM
who cares... there's a ux... use that?!

aurelien
25 May 2009, 1:42 AM
Sure, I do. This is about the management of this framework :


Upgrading
User upgrading to Ext JS 3.0, will be happy to hear there are little to no breaking changes. We took great care in only creating breaking changes where absolutely necessary. You may encounter issues upgrading if you were previously manipulating private properties of an Ext.menu.Menu or an Ext.Toolbar or if you had custom styling of an Ext.Button.

Following a tradition started with Ext 1.0, we are offering a pre-release sale with hefty discounts to upgrade your 2.x license. If you’ve thought about purchasing an Ext License, for a limited time, you can purchase online for less than an Ext 2.x License. There’s no better time to support the Ext team.

paladinjack
25 May 2009, 10:31 AM
i think the status bar should be kept...
it's not a pain to maintain it, and offers lot more flexibility

SunnySven
26 May 2009, 1:12 AM
I use the Statusbar Component too, I love it.
It is so fantastic and easy to show messages with icons and after a time let these message disappear.

I have to take a look at Ext.ux.Statusbar :-(

kaeptn
3 Jun 2009, 2:32 AM
I would like to object against the decision to exclude Statusbar from 3.0. STRONGLY if that helps.

We have an application based on 2.2 and use the Statusbar all over the place because it is handy and a well known UI concept.

This shortcoming of 3.0 breaks the migration right away and there's essentialy no backwards compatibility. Leaving a major feature out by saying "no one uses it" is really short sighted if not ignorant.

This leaves me not so faithful reagrding manament decision.

Mark Sisson
4 Jun 2009, 12:42 AM
Yep, I tried to upgrade this evening. My code broken. It was a waste of time to track down the issue, troll the forums, and now I'm going to have to club together something with ux. Not exactly what I was planning to do with my evening. But costing me an hour isn't really the issue, it's the attitude that's the real downer. This is amateur decision making. To hear that the decision was made because "nobody used it"... where in the world did you get your data from? How would you possibly know that? It makes me wonder what kind of other rouge decisions were made in the code base that I'm going to stumble on because I might be using a feature that was deemed unused.

I'm disappointed. I really want ExtJS to be the center of all my future UI architectures. I just hate to see this sort of stuff happen to a GREAT product.

aurelien
4 Jun 2009, 1:11 AM
Hello -

I'm developping an application and it's 70% done. I investigated yesterday to port my project to 3.0 right now. The ux status bar doesn't meet the same behaviour (I have a case where I don't succeed to show it, the layout put the height to 0). I have some customized menu items announced not compatible. I spent two hours to conclude it's a no go for me. I will propose an upgrade later to my customer. I can understand the evolution of the toolbars, menu items, etc. There is some work to do there for us. It's clearly explained and acceptable because of a big enhancement. But, the explanation for the particular case of the statusbar is not obvious.

Ext Team, it would be great to join us in the discussion here and bring something else that "it's easy to do, so...". It's clearly a gap for no "acceptable" reason. Ext 3.0 is in RC, it's not too late to review your position and perhaps bring back the status bar ?

Thanks -
Aurelien

PS: I love Ext. My customers love Ext. I do only Ext.

mschwartz
4 Jun 2009, 5:05 AM
Hello -

I'm developping an application and it's 70% done. I investigated yesterday to port my project to 3.0 right now. The ux status bar doesn't meet the same behaviour (I have a case where I don't succeed to show it, the layout put the height to 0). I have some customized menu items announced not compatible. I spent two hours to conclude it's a no go for me. I will propose an upgrade later to my customer. I can understand the evolution of the toolbars, menu items, etc. There is some work to do there for us. It's clearly explained and acceptable because of a big enhancement. But, the explanation for the particular case of the statusbar is not obvious.

Ext Team, it would be great to join us in the discussion here and bring something else that "it's easy to do, so...". It's clearly a gap for no "acceptable" reason. Ext 3.0 is in RC, it's not too late to review your position and perhaps bring back the status bar ?

Thanks -
Aurelien

PS: I love Ext. My customers love Ext. I do only Ext.

There's 2 ux versions, did you try them both? I didn't examine the 2nd one closely, but I don't see why the 1st would have rendering issues - it inherits from toolbar like the 2.0 StatusBar does, and there's not any magic to it.

4 Jun 2009, 5:31 AM
I still stand back and wonder what the commotion is. I realize folks feel like the rug has been pulled from underneath them. Would it be better acceptable if Ext JS just provided the deprecated class as a separate ux?

mschwartz
4 Jun 2009, 5:48 AM
I still stand back and wonder what the commotion is. I realize folks feel like the rug has been pulled from underneath them. Would it be better acceptable if Ext JS just provided the deprecated class as a separate ux?

There's an implicit contract between the API and the developer. When something is removed, it violates the contract. The cost to the developer is pretty clear from the comments here: "I use it all over the place in my 2.x app and upgrading is going to cost us man hours to resolve things like this."

My choice was that it is important for my project to use the bleeding edge version of Ext. I personally was willing to wade through several issues that cropped up in the porting process (2.x -> 3.x). But you can tell the pioneers from the arrows in their backs, if you know what I mean.

aconran
4 Jun 2009, 6:15 AM
Hey Guys -

I just want to let you know that StatusBar will be officially added to the ext-ux.js package by Ext 3.0 release time. We are working on it now!

It will be named Ext.ux.StatusBar and will also be aliased to Ext.StatusBar for backwards compatibility reasons. We hope that this will assist everyone in upgrading their applications from Ext 2 to Ext 3.

At this point, StatusBar will remain a ux and will be located in the examples/ux/ directory. The decision was made to remove it from the standard library so that we can add more things that we felt would be useful to a broader audience. We try to keep down on page weight and this is one way of doing so.

mjlecomte
4 Jun 2009, 6:16 AM
One change I noticed which I hope will help with this matter is that Ext 3 has a "ux" folder. This folder appears to house example classes and extensions. A couple of the extensions in the ux folder are from the community.

I think the idea is to convey that these are examples or extensions and not part of the library itself.

Personally I think it's great that some examples/extensions have been provided. I take the beggars can't be choosers mentality in that I'm glad the extension was provided in the first place. I don't think there was an intent to establish a contract that examples were anything more than that.

If everyone pushes that anything provided by Ext in the examples directory must be maintained then I suspect they (Ext) would have to weigh whether to add stuff in the future as the quantity expands.

Take Saki for example. I suspect he has more extensions in his portfolio but probably decided not to post some of them simply because he can't find the time to support all of them.

For me I'd rather have a widget than no widget at all. I think the community could support the ux's.

kaeptn
4 Jun 2009, 7:06 AM
IF the target is to cut page size THEN let the author choose what to include. Just let him configure which root level things get loaded.

StatusBar is such a root level component and aliasing it from the main framework to some extensions pack seems to me like you are pulling the hand brake now.

I'd personally would like to see a list which elements also went into the shredder and if they have been outsourced to an extension pack. Also, I'd like to know if the extension pack is officialy supported and maintained?

I really would have liked to switch my app to bleeding edge 3.0 RC2 since it is still in birth phase but I am hesitating, I have to chew and choke a bit on your main marketing line "A foundation to build on" ... sorry, but I am really disappointed about how this was done

mschwartz
4 Jun 2009, 7:18 AM
My preference would be to keep the ux stuff separate from the examples. kaeptn has the right idea, IMO. They shouldn't be ux at all, as ux implies User Extension. The idea of a plus pack that's official Ext things like StatusBar, MultiSelect, ItemSelect and many others that you'd selectively include seems like the way to go. Just Ext namespace makes sense.

As is, I started out <script src="ext/examples/multiselect/multiselect.js"> and that turned out to be a big mistake. I had to hack on multiselect.js and other stuff in there to make them function in the first place, and then function properly. Upgrade to ext-3-rc1.1 and the examples now have the code I didn't fix. Instead, the examples should <script src="ext/pluspack/Ext.MultiSelect.js"> and pluspack properly maintained (bugs fixed).

As well, the filenames of the sources really should have Ext. in front of them, IMO. When it comes to programming in general, there's a big issue of namespacing when you're including other peoples' work. Java does com.whatever.whatever type namespacing and it's a good thing. Ext does namespacing using Ext.namespace() which is great... the logical progression is to do the css (ext- instead of x- and ext-ux- instead of x-) and the source files.

My $.02

mjlecomte
4 Jun 2009, 7:46 AM
is to do the css (ext- instead of x- and ext-ux- instead of x-) and the source files.

My $.02
I think the "x" might also be for brevity. It's better than "$" IMO.

mjlecomte
4 Jun 2009, 7:47 AM
FYI, started an upgrade thread here FWIW (preliminary at moment):
http://extjs.com/forum/showthread.php?t=70352

mschwartz
4 Jun 2009, 7:50 AM
I think the "x" might also be for brevity. It's better than "$" IMO.

CSS gets cached by the browser, and gzip sending from the server will compress the hell out of 'ext' if it appears all over the place in the ext-all.css file...

I'm something of a namespace freak. I think I'll live to benefit from it one day.:D

kaeptn
4 Jun 2009, 8:30 AM
Excuse me folks, but CSS and upgrade stuff is bringing us off track here ...

Please, let's do what's possible to make this issue as important as it needs to be.

I for my part would have no problem to have a choosable set of components. Load them all by default and let the devleoper decide which page weight is acceptable for his applications and target audience and infrastructure. script.aculo.us has gone this way, why don't go the same way ...

Install the framework, create your app and configure things out you don't need. Done.

The biggest concern is that ExtJS 3.0 RC2 poses the threat of endless upgrading to exisiting applications be leaving out components which where present in 2.x

Upgrading from 2.x to 3.0 should be an easily followable path described by the dev team. Otherwise I fear that the paying customers will block so many ressources in requesting for upgrade help that other things fall behind.

aurelien
9 Jun 2009, 4:20 AM
Hello all -

Just a word after pushing this problem on the table. It seems acceptable to me and my customers.

Thanks Ext Team!

dbassett74
9 Jun 2009, 10:23 AM
How much weight would leaving the StatusBar have actually added? I mean, if it wasn't ultimately included by the developer, is there any extra weight? I'm also quite shocked that anyone would discount the StatusBar as being anything of value. Take a look at any window on a computer, 99% of them contain status bars. I think this decision was very short sighted and not well thought out. Seems almost more trouble to remove and include in the UX library. Why not just leave well enough alone? I say put it back!

tryanDLS
9 Jun 2009, 10:28 AM
Have you read this thread? Aaron has stated that it's back in for 3.0 final release.

dbassett74
9 Jun 2009, 12:19 PM
As part of UX, not the core, correct? Why not just make it available in core?

Jamie Avins
16 Jun 2009, 6:41 AM
Ext.ux.StatusBar is now in SVN build 4417.

griffiti93
19 Jun 2009, 8:16 AM
At our company we use the status bar for a variety of things, including:

Status messages
News alerts
Error events
Current logged in user
Currency default
Current customer


http://64.79.209.52/images/statusbar.png

dfenwick
21 Jun 2009, 2:54 AM
I'm typically on the ExtJS side of the house for most decisions (although I've been pretty silent for a year - go figure.) This particular decision, however, doesn't make much sense at all. It's a pretty lightweight widget that provides a very specific service and it does that service quite well. People used it. Removing it and turning it into a ux widget just doesn't seem very practical to me.

Just to give some credence to the whole thing, if you're a subscriber to ExtJS, aren't the ux widgets outside the support boundary you'd get from the company for the widget? I typically don't use the ux widgets in my UIs, um, ever, particularly if they're for a customer. The ux namespace is essentially an unsupported set of widgets (from a business perspective) so if we need functionality that's available in the ux widget set, we write it ourselves. This eliminates 2 possibilities: 1) The original author disappears from the face of the Internet (quite common) and 2) For specific customers we don't have to do a code review of the widget code before actually implementing anything with it.

I'm sure many of you have very flexible customers that don't care who/what/where you pull things in from. For many of the people I write code for (most, actually) I do not have this luxury. My customers (and myself) pay ExtJS specifically so if something breaks we can send a message and they're on the task. Have I done this before? Not often. Basically, moving the widget into the ux space removes that capability and it basically means we'd have to roll our own statusbar widget to compensate. Not to mention I can't really take the existing code because, well, it's copyrighted.

Anyway, that's my $0.02 from someone that's been using ExtJS since before it was even an alpha product. It doesn't make sense that something as small as this would be pulled out of the widget set.

deemonas
24 Jun 2009, 6:49 AM
Please please please.
Put it back into Ext core.

My project was affected as well :-(

24 Jun 2009, 6:57 AM
Please please please.
Put it back into Ext core.

My project was affected as well :-(


*Ext UI* not Ext Core!

kaeptn
8 Jul 2009, 4:19 AM
Well ... there's Ext 3.0 and Statusbar in examples/ux ... WTF ...

An example folder contains something which is essential for backup compatibility?

I am really loosing faith in how pro this here really is when a major updagrade break a major feature of its predecessor essentialy fully breaking backwards compatibility.

Please, don't get me wrong but many people made their clear statements that the initial decission basee on "nobody uses it" was plain wrong and that "keeping the footprint small" is a questionable argument.

Not even a structural way has been found to differentiate between plugins and examples.

I strongly dislike the decission made. A stubborn one with no apparent reason visible to me.

Please, somebody point me to the documentation on how to upgrade.

8 Jul 2009, 4:36 AM
I find it a bit amusing that you missed the FIRST (sticky) thread in this forum.

http://extjs.com/forum/showthread.php?t=70352

mschwartz
8 Jul 2009, 5:15 AM
Personally, I think the ux/ folder doesn't belong in examples. Seems to me it'd be more appropriate like this:

adapter/
docs/
examples/
pkgs/
resources/
source/
ux/

Edit:
And I think Ext.ux should be reserved for USER extensions, not official ones. So something like Ext.ext or Ext.pluspack or whatever would by my suggestion for official extensions.

I also hope that these extensions officially part of the ext distribution would be in the documentation proper.

cherbert
8 Jul 2009, 5:22 AM
I find it a bit amusing that you missed the FIRST (sticky) thread in this forum.

http://extjs.com/forum/showthread.php?t=70352

What is amusing about that sticky? And what relevance is it to the discussion at hand?

I too am dismayed that someone somewhere made a desicion to drop a intergral component to the Ext framework because 'they felt' hardly anybody used it!

Well as you can see from this thread, lots of people use it! And yes... I use it too! I won't repeat the arguments as to why having it as a UX component isn't satisfactory because others here have already done so.

I am a bit unnerved that the Ext team are seemingly ignoring this feedback so far.

mschwartz
8 Jul 2009, 5:26 AM
What is amusing about that sticky? And what relevance is it to the discussion at hand?

I too am dismayed that someone somewhere made a desicion to drop a intergral component to the Ext framework because 'they felt' hardly anybody used it!

Well as you can see from this thread, lots of people use it! And yes... I use it too!

I am a bit unnerved that the Ext team are seemingly ignoring this feedback so far.

Some people never view the actual forum to see the sticky. I know I don't. I've bookmarked the "New Threads" page and mostly use that and my UserCP page. A lot of the time I end up searching to find something I'm looking for and end up in a thread. Never see the stickies.

aconran
8 Jul 2009, 5:27 AM
cherbert -

We heard the uproar from the community about needing this component and therefore have included it as a ux. You can grab the relevant files from the examples/ux/ directory for the StatusBar.

mschwartz
8 Jul 2009, 5:29 AM
cherbert -

We heard the uproar from the community about needing this component and therefore have included it as a ux. You can grab the relevant files from the examples/ux/ directory for the StatusBar.

It was more of a clamour.

Or maybe a groundswell.

jburnhams
8 Jul 2009, 5:35 AM
What documentation is available for Ext.ux.StatusBar?

cherbert
8 Jul 2009, 5:35 AM
cherbert -

We heard the uproar from the community about needing this component and therefore have included it as a ux. You can grab the relevant files from the examples/ux/ directory for the StatusBar.

I think everyone in this thread understands that it is included as a UX. It works! No problems (Apart from nolonger being documented in the API docs!)

The discussion seems to have moved on to wanting it brought back into the main library. I guess you don't agree with the concerns raised regarding it being in the UX repository.

mschwartz
8 Jul 2009, 5:43 AM
http://extjs.com/forum/showthread.php?p=354588#post354588

The ExtJS guys don't seem unreasonable, but they're working on lots of things that lots of people bring to their attention. They're pretty good at responding to things like this.

bindu nukavarapu
8 Mar 2011, 12:56 AM
hi its all about status bar but i have one question how to add my own status message to the tabpanel