Frameworks like dwp store the ui in the db and can build webpages from that info. I'd like to have a wysiwyg editor for web screens that maintain ui definitions in a json or xml format, not dependent on progress and preferably open source.
Anyone seen such an editor / using it?
Excuse my ignorance, but what is 'dwp'?
This is an area that might be something for the Process Community Component Specification if there was sufficient interest. But any pointer to open source would be very good.
Some other thoughts I had: Internally, both Telerik Screen Builder and Telerik Sitefinity use a metadata specification for composite UIs -- these are not at the individual control, but more about high level layout, templates, binding, and navigation semantics.
For layout of mobile/tablet screens, Telerik's open source project for NativeScript defines an XML format for layout (similar to XAML). see http://developer.telerik.com/featured/demystifying-nativescript-layouts/
Personally, I always wonder about HTML -- it is an XML format that defines layout at the widget level. I tend to prefer more abstract defiitions.
Thanks for your reply Bill, dwp is the famous Peter van Dam framework. www.netsetup.nl/.../about-dwp. Of course their is f.e. the dutch javra also.
I'll let you know when I find something of interest. Seems a relatively unexplored area (but some keep their little secrets for themselves maybe ;-).
Hello Stefan,
Thank you for sharing the link.
The reference to the UI being stored in the database, reminded me of Progress Dynamics and applications based on a repository.
I wonder if DWP was based on Progress Dynamics at one point, one of the images in the web site seem to be using it.
Thanks.
Hahaha Edsel,
I don't know who was first. At the end the idea will have emerged outside the psc world. We all (well, all? ;-) share ideas. Psc owed a lot from others also. Even the biggest M.Fechner (hehehe) has been silently sneakily stealing ideas without .. (ok, I'll shut up). Who was first with the idea of datasets? Who with that of the jsdo? Where did the OO ideas come from? In most cases psc is more trendfollower than trendsetter. Nothing wrong with that of course (but prices for f.e. dnb licenses could be a bit lower, I'm really afraid more dutch customers will say goodbye in the near future.
Kind regards, Stefan.
Thank you for you reply, Stefan.
My point was not to start a discussion on where ideas come from and what ideas are original.
I had worked with Dynamics a long while ago and I was just curious about whether DWP used Dynamics at one point.
The concept of generating a UI from a definition in the database has a lot of potential.
I took another look at the images and they do not seem to be generated by Dynamics.
The main menu, toolbar icons and other elements are different.
Sorry for the confusion.
Regarding the feedback on the license, it would be good to bring it up to product management or to a sales person.
Thanks.
No problem Edsel, you're welcome. Regarding pricing I hope marketing is following communities also. But they will know of the issue by now. A message of me will not add much, I'm only a contractor.
Kind regards, Stefan.
developer.telerik.com/.../demystifying-nativescript-layouts
Interesting Bill! Thanks, I did not know of this. I'll take a look.
FWIW.
http://www.zebkit.com/ is one such a thing. I have no idea yet if the designer would be usable. But the link at least informs a webdummy like me of a couple more ideas, like the use of custom canvas ui elements instead of html/css. It uses json to store / build the ui from www.zebkit.com/.../json-like-ui-definition.
Another one I did not dive too deep in, but it has the ui in xml:
http://logand.com/sw/webglade/
Will search for more.
Another one (generating json):
http://extjs.org.cn/node/298 has direct working download links
extjs guidesigner 2.1.0 (link to online version & sourcecode in prev mail) was the last os version of the product. It was bought by sencha and became ext designer and later sencha architect. Use http://unminify.com/ or http://jsbeautifier.org/ to make minified js files readable.
Small informative link about creating forms in json etc. daffl.github.io/.../jquery-dform.html
Would be nice to hear others - expecting total silence, are those the NDA's again? :-( - about added values that this json based dynamic ui building would give. And maybe someone could think out something for the ccs project (community.progress.com/.../19086.aspx)? Bill?? Here's even another os project for mobile views based on json github.com/.../json2view, might generate ideas.
Not doing any webui development at the moment, but to me a big value in dynamic UI building is that the UI can be customized without changing code.
The fact that it's stored in a json format is IMHO not so relevant, it's just a data format that is popular right now.
The json describing the UI could be the result of customizable queries on data. e.g. different queries for free version vs paid version. Customer specific additions/removals/ ... .
It depends on the render/generator tool how good the end-result would look.
At the speed that UI looks-and-feel change you could hope that the data describing the UI remains relevant even if the tool to create the UI changes.
Thanks Carl,
> The fact that it's stored in a json format is IMHO not so relevant
When the designer (not a tool written in progress) stores the ui in json format it could be easily picked up by progress, and other languages I suspect. It could be stored in blob fields or be decomposed to a relational datamodel and stored in different tables / fields. Read actions would be quick when the json can be read as a whole from blob fields. Some caching could help performance.
Json (JavaScript Object Notation) is easily digested by the client also, of course. XML takes more space, can be expected to be less performant.
> The json describing the UI could be the result of customizable queries on data. e.g. different queries for free version vs > paid version. Customer specific additions/removals/
Interesting idea.
> At the speed that UI looks-and-feel change you could hope that the data describing the UI remains relevant even if the > tool to create the UI changes.
A lot of styling can be done with css. You can design the designer as future-proof as possible, but of course you never know what is going to happen the years to come. The designer in any case helps separating concerns.
This thread leads me to a few conclusions:
1. The number of designers out there, all with different formats, leads me to think that there are no clear preexisting format that is dominant. XAML, or HTML itself, is probably the largest.
2. The comments about "styling in CSS", and "UI looks-and-feel change" imply that you don't want a WYSIWYG designer, but rather a more abstract definition -- I think you also need to have an abstract layout manager to deal with the new realities of browsers, or form factors for Tablets and Phones, and flpped orientation.
3. The recent comments tend to move from "json format" into 'a relational datamodel' (or other persistence options) and dynamic runtime generation based on "customizable queries [for different user roles]".
All very interesting.
Hi Bill,
On 1. Do you see a relevance for dominant formats?
2. It would be handy to be able to assign more properties than just position width height to a 'widget', classes would
be on the wishlist (these could be picked up by the stylesheet). Some others would be: tether bolts for events,
tabindex, and for example not a label as this can be multi-language
3. I see Json as a good format for the designer to persist the ui on the client for the reasons already named. I prefer a
designer that is usable without a backend (offline) and it should be ignorant of backendtypes. It would be handy to
be able to bind temptablefields (eh, catalog-things) to widgets (see wishlist for extra properties above).
On the backend the json can be persisted in a blob field (database). The relational model could be in-memory as a
dataset representation of the named blob fields. From that representation in memory a new json can quickly be
dynamicly constructed if needed. Besides there could be good reasons to persist the data in a relational model in
the db.
I'm a bit jealous Bill, are you going to build this yourself now? Hire me, I have to build it myself anyway. :-)
There is an *much* better alternative for storing ui definitions in json in a blob type field in the database. It is the json (and preferably jsonb) datatype.
About the json datatype (why what how):
functionwhatwhat.com/json-in-postgresql
www.postgresql.org/.../datatype-json.html
new in postgres 9.5, see jsonb : wiki.postgresql.org/.../What&
I asked for it before, in a massively voted (not of course) idea f.e. here community.progress.com/.../next_gen_database.aspx
Thoughts?
extjs guidesigner 2.1.0 has layouts btw. To see them download 2.1.0 (see the link in a prev message) and open index.html in firefox.
WireframeSketcher (marketplace.eclipse.org/.../wireframesketcher-wireframing-tool) is using an uml/ecore model behind, much like our ERD tool (ganimede.ro/.../zamolxis-erd-psdoe-integration)... that can work very well with 'abstract UI components' and have generators translating the mockups to different component frameworks.
Another one for in your dark room discussions (grrr! it's like throwing ideas in a black hole: not very rewarding): korynunn.wordpress.com/.../deploying-a-web-app-in-14-days-no-html
The idea of loading ui definitions in json format leads to the thought that only one, basic/very small .html is needed.
"a few big advantages:
Some more things to think about: