Announcement

**Isomorphic** · 11 Jul 2013, 12:37

In the default contentsType:"fragment" mode, you need to enable HTMLFlow.evalScriptBlocks if you want inline JavaScript executed.

This is not *quite* like a normal web page. We wouldn't recommend it for developing anything substantial. We're not sure why you would bother with angular.js at all, but if you have a reason to use it, you'd want to load it normally via <script src=>, and try not to rely on embedding <script> in the HTML you use it with.

**esmith** · 12 Jul 2013, 05:15

why

Hello,

Well if I have a backend that has lots of data points that are being updated on a html page. Then angular seems like a nice way to get dual binding. Not something I can see how to do in smart gwt.

Evan

**esmith** · 12 Jul 2013, 05:31

no luck

Hello,

I tried to take the suggestion so did the following

htmlArea.setEvalScriptBlocks(true);

and changed from HTMLPane to HTMLFlow type.

I left the script src = as it was, as I was not clear what to change (or if it was fine as I suggested).

I changed the ng-app back to the <html ng-app> as thinking it was my own html page in the htmlflow.

So what did I miss to get this hello to work?

Evan

**Isomorphic** · 12 Jul 2013, 11:06

That actually wasn't our recommendation - our recommendation was to load angular.js normally - see above.

**esmith** · 12 Jul 2013, 13:08

How to load normally

Hello

I am not clear on what the normal way is.

How. Where do i load the scripts? I tried both the url i am setting. And my main html file.

Evan

**Isomorphic** · 12 Jul 2013, 13:34

Adding it at the top of your bootstrap .html file would be considered the normal way.

We would also recommend not putting any inline script in the HTML you load via HTMLFlow.

At that point you'll just have ordinary HTML in the DOM and ordinary script loading, and SmartGWT is not involved - anything going wrong at that point is something to do with angular.

**billw** · 14 Nov 2013, 15:00

Originally posted by Isomorphic View Post

We're not sure why you would bother with angular.js at all, but if you have a reason to use ...

Because it has a lot of merit, works with standard HTML and CSS, is highly testable, and saves a lot of development time.

Cheers,
Bill W.

**Isomorphic** · 14 Nov 2013, 15:07

Hilarious :)

If we can make an analogy: you can find many sites and pages out there where someone has asked "what's the best web framework" and there are hundreds of responses.

Anyone who answers this question should not be listened to, because the only correct response is: "for what purpose?"

We don't know of any enterprise application UI where angular.js applies. It does seem to have use cases in certain lightweight websites where JQuery also applies.

If you can point out a use case in the enterprise application space where angular actually provides a better approach than our technology, that would be interesting information (although the result will most likely be a small feature that covers the use case better :)

**billw** · 15 Nov 2013, 13:38

Originally posted by Isomorphic View Post

Hilarious :)

Glad you are amused. :-)

Originally posted by Isomorphic View Post

If we can make an analogy: you can find many sites and pages out there where someone has asked "what's the best web framework" and there are hundreds of responses.

Exactly, which is why it's always good to do your own research, and experiment with some of the top contenders on your own.

Originally posted by Isomorphic View Post

We don't know of any enterprise application UI where angular.js applies.

Now I am laughing. :-)

Originally posted by Isomorphic View Post

If you can point out a use case in the enterprise application space where angular actually provides a better approach than our technology, that would be interesting information (although the result will most likely be a small feature that covers the use case better :)

Excellent. We'll be happy to report back in a couple of months with a comparison of version 1.0 of our enterprise application written in SmartClient compared to version 2.0 written in Angular.js. And we will give a point for point comparison, and an unbiased assessment.

Cheers,
Bill W.

**Isomorphic** · 15 Nov 2013, 16:20

Excellent. We'll be happy to report back in a couple of months with a comparison of version 1.0 of our enterprise application written in SmartClient compared to version 2.0 written in Angular.js. And we will give a point for point comparison, and an unbiased assessment.

May you fare better than the other projects we've seen go down in flames from similar switches.

If you're going to report back, please report back at an appropriate phase, that is, after you've actually deployed the app to end users and gotten the reaction.

This will give you time to:

1. find out that there are just as many cross-browser issues as ever these days, such as IE leaking memory whenever <img> tags are added and removed from the DOM, or border-radius+background gradients not working in IE9 without special tricks. That's the tip of the iceberg; you'd be amazed how many bugs we file.

The fact that all browsers are now passing CSS layout tests like Acid3 has created a trend where people think it's now safe to code directly to the metal. It'll be a short trend.

2. have your users say "where did all the features go?". This is a reaction we've seen a number of times from the severe downgrade to grids, export capabilities, charts and other components that comes from switching away from SmartClient. Developers don't realize that uber-powerful grid features like formula columns, grouping, highlights, Excel export etc were actually being used, and they are flooded with complaints about the need for features they had gotten for free with SmartClient.

But that's just our experience from watching this happen a dozen times or so. Maybe you'll be different!

Also, to provide a real comparison, be sure to give an idea of the overall scope of functionality in your app, and what functionality the most complex screens provide.

This is critical information because of another silly trend we see a lot: building a trivial app that could have been built easily with absolutely any technology, declaring a brilliant success with many terrific benefits realized from the technology, then running into the wall on the next revision when requirements are non-trivial.

**billw** · 16 Nov 2013, 05:33

Originally posted by Isomorphic View Post

The fact that all browsers are now passing CSS layout tests like Acid3 has created a trend where people think it's now safe to code directly to the metal. It'll be a short trend.

Where do you get the idea that Angular projects need to program the DOM to the metal? Angular projects use JQuery, Bootstrap, and other widely used and proven technologies. The Kendo UI team even did a complete refactoring of their UI components to fit into the Angular framework:

Announcing Angular Kendo UI

Originally posted by Isomorphic View Post

2. have your users say "where did all the features go?". This is a reaction we've seen a number of times from the severe downgrade to grids, export capabilities, charts and other components that comes from switching away from SmartClient. Developers don't realize that uber-powerful grid features like formula columns, grouping, highlights, Excel export etc were actually being used, and they are flooded with complaints about the need for features they had gotten for free with SmartClient.

You're not saying that SmartClient is all or nothing, are you? If someone really needs these grid functions, can't they be used with other frameworks?

Cheers,
Bill

**Isomorphic** · 16 Nov 2013, 09:17

Using a component framework rather than raw Angular/JQuery is smarter, but in that case the comparison is rightly between SmartClient and the component framework. In this case, the nearest competitors for enterprise use aren't based on Angular (or JQuery), and any plans to deeply extend such frameworks run right back into the problems of direct-to-DOM coding.

You're not saying that SmartClient is all or nothing, are you? If someone really needs these grid functions, can't they be used with other frameworks?

Obviously not, as we extensively document how best to integrate with other components.

However, this is another commonly taken dead-end trip, since combining any two component frameworks makes it nearly intractable to meet basic enterprise needs around accessibility & modality handling, makes other basics much harder (branding, i18n), and in any case, forces you to deal with the reconciling the internals of two component frameworks, lowering productivity.

**billw** · 16 Nov 2013, 13:46

Originally posted by Isomorphic View Post

Using a component framework rather than raw Angular/JQuery is smarter

This statement makes absolutely no sense. We all understand what a component framework is, SmartClient and ExtJS are two great examples. But what is the derogatory term "raw Angular/JQuery" supposed to imply? This, plus the comment "why bother with Angular at all" leads one to believe that you really do not understand what Angular provides. If you were to compare a component framework over JQuery alone, I might agree that there are advantages to the former. But a combination of Angular and JQuery (or even Angular with its jqLite implementation) provide a full featured MVC framework. This is where the comparison must be made--not to "raw" anything. Such a statement is the exact kind of thing that you warned people "should not be listened to" in your earlier post. And a framework that provides direct control over the very elements that make up a Web UI should not be mistaken for the pitfalls of raw DOM programming. This is not the case at all.

Cheers,
Bill W.

**Isomorphic** · 16 Nov 2013, 16:57

Bill, please realize that SmartClient pre-dates JQuery, that SmartClient contains all the same sorts of DOM manipulation logic as JQuery, that we've worked with several large JQuery codebases while migrating clients away from it, and that we've implemented features for clients that involved JQuery in the rare cases this makes sense.

You may have questions about our assertions, but you can go ahead and assume we've not coming from a position of ignorance.

The level of abstraction provided by a framework corresponds to the number and type of browser bugs it can save you from. When you are using a ListGrid component through it's API, we can ultimately save you from just about anything.

When you are manipulating sets of Elements, even if you are using a wrapper object over each element, there are lots of bugs you cannot be saved from, because the bug is not related to a single Element but its context. These include various kinds of memory leaks, layout and size reporting bugs that arise from the combined placement of Elements, event handling and keyboard focus issues that are sometimes related to the entire DOM at once.

This is why you shouldn't be using an Element-oriented API unless you absolutely have to. This is what we mean by raw JQuery / Angular usage, and/or direct-to-DOM coding. You are exposed directly to the structure of the DOM. The fact that you access DOM elements mostly through a thin wrapper API can save you from certain kind of bugs, but not from the subtlest and most pernicious bugs.

As we've covered, there are some component frameworks implemented on top of Angular and JQuery. These *could* save you from the worst of the browser bugs - if you stuck only to the component-level API and never used direct Element manipulation. But then:

the nearest competitors for enterprise use aren't based on Angular (or JQuery), and any plans to deeply extend such frameworks run right back into the problems of direct-to-DOM coding.

Announcement

angular.js

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment