I would like to take a simple web page, and allow non-technie administrators to modify content simply by logging in, browsing to the page that is to be changed, and clicking on text to change things, or drag simple lists to re-order them.
My question is whether qooxdoo would be a good choice for this use case. I would want the text to display as it normally does, with magic htmlarea appearing on click, and similar features that don't disturb the visual layout.
The HtmlArea is also available as low-level component optimized for the use at traditional web-pages. So yes, qooxdoo might be a good choice for your use case.
Since no UI-widgets (high-level) are involved the memory overhead should be acceptable here.
Just take a look at the namespace "qx.bom.htmlarea" which entered qooxdoo with version 1.0.
Since you can use qooxdoo widgets in a normal webpage, and it has good DOM handling functions for picking and manipulating elements off a page, this might work quite well. But you may have to tread with caution to prevent having to reload the whole qooxdoo code as the editor switches from one page to another while admining since qooxdoo code is quite heavy. I could imagine something with an iframe containing the original site might work ... on the other hand there are already quite a number of CMSes out there ...
qooxdoo offers a Low-Level Library [1] for such DOM related tasks, if you don't want to have full qooxdoo widgets in your site. If you would like to have a qooxdoo list for example in your website, that's not a problem too. Take a look at the inline Apps [2] for those kinds of things. The DemoBrowser offers a nice demo of an inline App [3] which can give you an idea of how it could look.
Your use-cases are all possible with qooxdoo so I think qooxdoo is a good choice if you want to have a quality code base including all you need.
[1] http://qooxdoo.org/documentation/1.0#low_level_framework
[2] http://qooxdoo.org/documentation/1.0/ui_inline
[3] http://demo.qooxdoo.org/current/demobrowser/#root~Inline_Dynamic_Resize.html
Related
I know that polymer is primarily used to create reusable elements, and angular is supposed to be used to create web apps (at least from a "high level" perspective), but I wonder, since you can wrap your own "Screens" as polymer elements, which actually could serve as controllers too, and switch the active page with the iron-pages element (see SPA demo), and you can also use more-routing well... instead of "routing by code", it supports one/two way binding and events, I've actually done some small SPA app like that myself, and so far so good actually! moving on-
Assuming I don't care about having some built-in REST wrapper such as the one provided by Angular (Easy to roll up my own if I use Dart), then in Dart's case:
Could polymer actually be used to create full apps?
Would it have any implications in performance if my whole app is in polymer? by that I mean, every screen is really an element, and so on.
Development speed, maintainability, and experience? (considering the fact that I use Dart which helps a lot in these areas)
Overall, is it a good idea? I'd like to know your opinions.
Any companies/indie devs have done this before? not necessarily with Dart, but with TypeScript/JS as well, although I'm 100% set on Dart.
I think Polymer is quite a good fit for that. I wouldn't necessarily go for "a Polymer element per page" but that might depend on the kind of application you are going to build. Especially in Dart Polymer it's a good start to make the root Element a Polymer element. You can for example keep the navigation and switch only a part of the view instead of the entire page (but that might be what you had in mind anyway)
You can also use dependency injection, which is a strong point of Angular.
The dirty checking might be better in Angular 2 but Angular isn't released yet and Polymer also has plans to improve here.
I'm looking for dock layout engine for angularjs written in typescript. I found Dockspawn but it is written in DART and it's not compatible with the rest of my project. Does somebody know any dock layout engine (even paid ones) for angularjs in typescript?
I think your real problem is that dockspawn was abandoned. This is something I built at my company (which, sorry, we don't sell software)and it turns out that Angular is the worst thing you could use to build a layout engine like this.
Managing scope chains among components that are constantly changing positions, opening/closing, resizing, and floating is entirely too complicated for this type of project. You will end up with 15 step bug reports everywhere, and unless you have a perfect algorithm set in place before ever developing anything you will end up spending weeks re-writing code.
Solution (and not the one you want to hear): drop it. Web design is meant for developing pages within the browser, not for developing windows with tabs within your browser window which is full of tabs. The control and flexibility is very nice, but there is always a way to provide the user with just as much control by setting up panels on the page in the positions in which they will be consistently used the most.
Sooner or later someone will develop what you are looking for and release it, but it probably won't be in Angular and it's definitely going to cost money.
You should be able to use Dockspawn because at runtime DART is JavaScript, so as TypeScript. You just need to find a way to make TypeScript aware of Dockspawn and you can do that using a Type definition file.
The types definition file for Dockspawn is available online.
You can install this kind of files using a tool known as tsd. You can find a basic example here.
i want my websit ui of flash or silverlight quality, but want it to work on any browser by default, i.e not asking for installing flash plugin. is it possible ? what technology should i look at ?
Well, it depends on what kind of "UI quality" you have in mind.
If you want something static, pure HTML will do the job.
If you want dynamic UI, HTML + Javascript is probably your best option right now (AJAX if you need to deal with the server without refreshing the whole page).
HTML 5 will also offer you more UI possibilities if you don't mind waiting for it.
However, some plugins features (like 3D acceleration) will be difficult to "emulate" even with HTML 5, so before choosing which technology is suitable for you, defines whats your real UI needs are (for now and futur development).
you could use javascript with a library such as jQuery to help. But there are things the both Flash and SilverLight can do that html+javascript just cannot do.
HTML5 is around the corner...Which to some extent can do a lot more...
I don't know if it's just me, but I really enjoy some application's GUI designs, apps like iTunes/Avast, or some media players like KMPlayer. So I was thinking of making my GUIs look different and I later found out that it's called a GUI skin (am I right?).
I read somewhere that it's not such a good idea to use or make them regarding app's speed, usability and all that. So the question is: Is it good and safe to make GUI skins? and if so, how could I start programming one (cos I don't want to use off-the-shelf ones unless they're really great). What's the main idea behind them. I am expecting to be able to change the whole form's look and feel and possibly change it's shape.
Any idea on this is greatly appreciated.
Good or Bad?
Bad. I don't have a nuanced answer for you. I don't have a bunch of exceptions. I don't have a thoughtful essay to write on when skins might or not be appropriate. I have an unequivocal: Bad.
Custom skins are the cancer that is killing the Windows UI, turning it into an ugly, unusable jumble of mixed metaphors.
If you must theme because your app is the exception and you're just so cool, please provide an option to turn it off and use the regular OS theme. Not a skinned approximation of Aero, Luna or Classic, but the actual normal OS theme, whatever (potentially custom) theme is chosen.
As far as I am concerned there are two kinds of applications that might be skinnable: Media players for example might benefit from looking like an actual physical appliance (PowerDVD or so did that, iirc). However, the actual use cases for such things are very few, if any – the trend today seems to be that such applications have little to no UI and instead concentrate on the content (VLC is an exception).
Then there is the large host of applications where either developers or managers got creative or too much time on their hands. Raymond Chen calls this “I bet someone got a really nice bonus for that feature.” – a sentiment I deeply agree with. First of all, skins are often a non-feature; the novelty wears off really fast, they don't actually help a user with whatever problem they're having to use your program and finally, for many programs that exhibit skins, there is really no need at all. I mean, come on; how often do you open your AV program, or your graphics card settings panel, revelling in the glory of its beautifully and carefully-designed skin? Never, right.
So then is the question why you even want to devote development resources (either your own or others') to create something that serves no useful purpose, except making your application stand out visually. The windows UX guidelines also have something on window frames and branding. Note here especially the following section:
Don't use custom controls for branding. Rather, use custom controls when necessary to create a special immersive experience or when special functionality is needed.
Incorrect:
This example shows a custom control incorrectly used for branding.
Gadgets are another type of application that can get away with custom designs, but then again, those are often only used shortly and serve generally as either informational things or with ephemeral interaction.
If you do skins, do everyone a favor in making it (a) optional and (b) use the standard controls and just paint them yourself. This enables accessibility tools to still know what your program displays instead of just seeing a bunch of picture boxes that are used as buttons.
Couple of year ago I when to work for company as web developer. It has my first Sirius web development job, (ASPx/C#) so it has very exciting and I learned a lot about that world, from the developer point of view.
In that group we had a concept for the pages where loaded in the page UC’s (User controls), I don’t know if it’s the same in every web development team with every language, I’ll assume it is so.
The contract ended and I came back to develop win32 “winForm” application.
But since them I have tried to apply the same principle for my win32 development I learn there, meaning having bunch of UC’s (Visual User controls) that I load in the form.
They are regular visual components, not loaded in the toolbox, code is available in the project, but the component is not developed in the form, they are loaded there.
I would like to know opinions about this approach, what other are doing similar or better to this And improvements that can help us to speed up development and increase code reuse, because that is what this is all about.
If you're using the layout components in Winforms, this might be an acceptable approach although I think the thing that distinguishes the web and Windows Forms (note: NOT WPF!) is that in the former you do a lot of "compositing" which is why the UserControl concept is so useful whereas in the latter you operate on very sophisticated controls (e.g. 3rd party - in my last gig we used an incredible grid control via a small company called Infralution)
The main problem I would see is with layouts since the rendering model is a little different than the web. I know nothing about your application but if it "works" that is what is most important. I assume in this case you use things like the FlowLayoutPanel and the TableLayoutPanel properly.
If you want to go a more canonical route, take a look beyond simply creating components at how you can use the inheritance model to composite your application in a more robust way - having a base Form class that has containers for where your "UserControl" type components go and then using some kind of interface based dependency injection to swap them out while the application is running.
Finally, take a look at some of the open source Windows Forms applications out there to see if you're being too hard on yourself since common UI and reusable components are a goal in every application. Even though I've always thought Microsoft's Patterns & Practices stuff teetered towards being bloated, there are some good ideas and you should study some of the approaches of the Composite UI Application Block they put out.
Okay, not finally, there's one more thing I'd like to add: take a long hard look at WPF which will bring back a lot of the concepts from your web development days and give you that kind of power in a desktop application.