@ Richard:

"the main problem with MusicShop is that, beside it seems cool and complete, it's far from it !"

Cheers, mate :) ... I like to read that, while it is not myself who writes this :)))

@OSIE:

CRUD is a nice thing ... but today you do manage your stuff in other ways. I guess the CRUD comes from the Uniface demos, where you would use it to navigate throug the occurences. But Richard is right ... it seems a bit outdated. But if it works for your project then it's ok

:)

The last time I did CRUD was back then in 2008 when I first came across the [F1] tutorials within Uniface. Things has grown smarter ...

Good morning,

The sample you have bee looking at is the same technique as on the stuff I write into my contributions- the thing I'm preaching for since back then ;) It's called templating. Templating can be done upon everything you do (while writing software) as the code doesnt care. The Sample uses my COMMUNITY::ONE (written in PERL) to get it running. Same is used on udev.info and on U-B-G.org. Here in the Office it's Uniface and meanwhile I'm porting my COMMUNITY::ONE to C++ for speed and memory reasons (the "next big thing" shall  serve about 100-200 people at the same time- a browsergame ) ;)

What I want to point out is that you don't need to make your mind in WHAT it is done. If you can disconnect the frontend from the code controlling the stuff, then this is it! :) I've done so and I don't care about the code behind any longer. Here are some screens, showing Uniface with the same codebase, same server and even SAME WRD:

[[Media:2361953]]
Well, now thats, what we mostly use

[[Media:2361954]]
This pinky thing was created for the german user group summit back in 2009. Actually they liked it and so it went to be the layout for their website (www.u-b-g.org).

[[Media:2361955]]
And this dark thing is a project, where we tried something new. The project consists of less than 8 USPs, some services and is pure RIA. Those USPs deliver more than 60 (!) screens and uses CANVAS (HTML5) elements for gfx here and there. Further to be mentioned are the PULLDOWN menues aswell as drag-and-drop elements ...   I really like that thing ...

@Richard: " ... I'm not saying Don't touch Uniface RIA with DSP (as Ghan would do :-) ) "
Oh, come on, don't be that hard on me :) Just accept that I found my way through it all. I've been living this for the last 2 years while nobody listened ... and I still think, it's about to wake up the neighbours :)) But, well, lett me fix your statement to something fitting: Take the journey with the DSPs, learn and understand and then realize the limits!

Thats it from my side ;)

Hi

I totally agree. In my point of view, however, the main problem for sharing for now is the lack of standing back, and the lack of support for those new development, exposing us to share solution that might seem good, but will be proved to be a bad hack in the future.

The kind of discusionn we all have now, in this thread, demontrates this fact, but is also a good insight on the importance of a community, sharing more, and in a more organized way, than it did in the past.

Well I guess we all are in the same sort of boat...

DSP's are optionally (why not ) a good place to start, but if you want to get your hands more dirty then USP's can offer more... or do the lot in a 3gl.  For unifacer's who like to remain so, the ideal senario, would be a uniface solution but there is a much lacking repository of help and tools provided by uniface... Its sad becuase a lot of work has gone into the development of uniface.  License restrictions also limits the potential of more developers taking on uniface and hence again restricting the pool of ideas.

As DSP development gets more advanced there are cases where one must include a hands dirty approach.  I guess this is how it is.. the more 4gl you go, the more restricted you are, but the easier it is.

At the end of the day.. we all think web is the way forward however one climbs aboard and shared knowledge in a little pool is better than no shared knowledge at all.

osie

Hi Richard,

the missing functionality you mentioned is the same we "enjoied" with the tab widget and the different tab pages:

the component-focused way of uniface does not provide any support for "orchestration" and interaction control.

AFAIK, it is still a lot of "hand crafted" glue necessary.

But paying for supported licenses, I think the best is to convince CPWR that they "fill  the gap" and provide usable tools
and concepts for all their paying customers.

Same goes for osies standpoint:  (101%) YES, the whole should be designed to serve a "unifacer";
no need to be "a little more open to web programming, and open up another battlefield".

SUccess, Uli

P.S.: wish CPWR would provide more (free of charge, we own sopported licenses) background whitepapers and
proof-of-concepts how web 2.0 programming is a fun with uniface DSP.

Not only a "here is the code, interpret it if you need to", but a sound papaer about implementation decisions and variations.

Other worlds outside unifaceland (like my preferred eclipse environment) are light-years ahead if it comes to spreading knowledge,
wisdom and excellent foundations for their user communities.

Hi Osie

I important thing MusicShop does not demonstrate, is the limitation in inter-DSP communication. A parent DSP can always talk to its children (via operations), the inverse is not always right, even more if you try to introduce a bit of genericity in DSPContainers, with more than 2 levels of imbrication.

As I and a collegue of mine mentionned elsewhere on this community site, Uniface lacks a bit of dynanism on this point. So if you don't plan to hack to find solution, as we did, be prepare to limitations on DSPs organization. This's not an alarm, I'm not saying Don't touch Uniface RIA with DSP (as Ghan would do :-) ), Compuware seems to go the right way, but there's some tricky DSP behavior, at least for now. Good understanding of how Uniface RIA works is important to make the right choices.

However, MusicShop still is a good learning tool, because its an avdanced sample.

Best regards,
Richard

Hi

Thanks for the thoughts.

@Uli : I quite agree that there is more than one way to skin a cat --(metaphorical, not literal ).  I looked into something similar a while back (appfuse) but I realised that at the end of the day I am a unifacer.  And although it is not free it is not worth the effort, for me, to make such a radical career change.  Also, my client base would be existing uniface projects where it would be an advantage to use the existing uniface model and already gained knowledge.  9.4 seems to make this all possible.   I assumed you were in the same boat.

If I were to go open source then I think uniface 9.4(having already good knowledge of uniface) is a great springboard to start with... The first steps for me are/were what the hell is a tomcat :-D, and so uniface has web-onised me.  After some web applications under my belt open source may well be the way forward.

@GHAN

Thanks for the tips.  I agree with all you said and think that my development path is the same you refer to.  Was the link writen in uniface USP'S with Ajax?

btw: The applications that I envisage writing will be less dependant on pictures and moreso on data..  In fact they would be a typical client server application with the advantage of being able to run via the web.

osie

Hi Osie,

taking the MusicShop to get a glimpse of what can be done is not that bad. But you should turn the back to it, if you want to put your own ideas in place. If you want to do a shop, then take it as an initial view. As Richard already mentioned, iMusicShop is far from complete (and as far as I remembered, Gerton never claimed it to be perfect- just a techdemo). And you will never know what you will miss while using it as your foundation upon a new development.

So the best thing to do is just to take a pencil and paint some stuff together. I did so for you:

[[Media:2361693]]

 I don't want to say: "Do it with THIS or THAT!" ... do it, with whatever you want :) That's the only way.  "My way or Highway!" ... :) You are in charge of how to manage the project, so you may choose how to manage and support it. Everything is allowed as it is maintainable, I guess!

What you see is some areas of a typical web page. There is a HEADER area, where logos, images or other visual things belong. Below of that, I've painted a NAV1 (Main navigation area). Here, I offer different topics for a Shop, site, service. Below that you see a MESSAGEFRAME in which all kind of feedback has place (e.g. "Saved!","Failed!", "not available").

Then we have a co-nav called NAV2 on the left hand side and the main CONTENT on the right. All this is finished by a footer holding typical stuff like the disclaimer or contact information. All this is just an inspiration. That's how I start off.

Taking the experience to something new

As you wrote, you did make tabs, which again opened new things here and there. Try to port this knowledge to your own new things! And if you don't have any idea, then try to get the drawing running with the dsp's. Doesn't matter how, just do it :) The experience gained will help you, to succeed in new stuff.

Maybe this helps you on your road to RIA.

kind regards,

-GHAN-

PS: If you need some other ideas on how a shop could look like then here comes a goody for you: http://www.postorder.de

- 30.000 items
-109.000 images in three sizes
- GHANIFIED! Javascript
- Multilang supported (they are building the danish text's by now, english is next)
- about 400 Users a day
- same technique as demonstrated on udev.info (and in fact the same code as on udev.info)

Hi osie,

I support your view to explore "what is already inside the uniface package".

If we decide to implement far away from the "pureest uniface",
there are a lot of frameworks/concepts/utilities which do not force you deep in the web programming codework.

Just like we can do it in uniface, all you need is to specify what you wanna do and let the platform take care of the rest.

If you just look what is possible with the different approaches in ine eclipse environment (RIA, riena, redview, ...)
you find similar comfort like we enjoy developing with uniface plus the bonus of open-source (beside the no-license-feeas):

A lot of different people ("the community") are involved in a very fast inovation,
transforming their expertise into usable tools and providing features they need in their day-to-day work for all of us.

Beside Eclipse, there are other interesting alternatives like Clojure:

I attended a workshop last week on nowadays development on top of the JVM (Java Virtual Machine)
and was very impreressed how easy web-development can be from a higher level of abstraction.

Will drop some lines on the dITo digest after I gained more experiences in that area

Success, Uli

Hi GHAN

I am not in favor of DSP'S over USP or visa versa... but without anything to work with I have taken my only ready-to-play-with application, hence MUSICSHOP.

The original crud post was just to have something to get ideas.

I would say that I am now on stage 2.  I have soft tabs which generates a menu system with main function tabs which invoke sub- tabs to run DSP's.

And now looking into generating DSP's to do other functions other than crud.

So basically building functionality on to the musicshop concepts.... I re-iterate that I have taken the musicshop angle as I have nothing else to work with.

I am interested if you think that one can build on to the music shop to create a viable business application or that you think an alternate approach is necessary.  If so what?

Can you suggest a few functions when you refer to 'manage your stuff in other ways'

Thanks

osie

Well ... I don't think this has to be taken in a personal way. Somewhere is always a "hello world" for whatever (mine was last saturday again). And thats pretty fine for a start! (atleast for me). I want to learn, so I will go out there and give it  try. I suppose you to do the same here. And still I dont know, who else is trying DSP's and RIA out ... but I'm sure, that there are many others among us.

So ... keep it up and make yourself comfortable with web and the related stuff.

:) ... It's supposed to be fun.

Hi Richard

I quite agree that a business application is not just based on CRUD... but it will have simple CRUD screens that will need converting if you are doing an entire conversion.

The first problem for many, is how to convert an excluisive uniface knowledge into something much wider... router, servers, web etc etc.

The second problem for many, is that uniface 9.4 has much much more functionality that the uniface 5 type stuff that we have relied on for so long.

My approach is to convert those simple screens...  realise stateless problems, paging and anything else along the way.

Apply this gained knowledge to develop more complex processes.

-- To see your ChUI application data suddenly appear on the web is quite something

One has to start somewhere, and for me personally 'hello world' has always worked in the past.

Thanks

osie

Thanks to Uli, I have got the bit of code I was missing. 

I think DSP's are great, simple and quick.  I can not understand why we are not overwelmed with examples and ideas.  I would offer mine but at the moment it looks just like the music shop but with my own data and a save button. 

I look forward to seeing more RIA chat in the coming months.

osie

Hi

the main problem with MusicShop is that, beside it seems cool and complete, it's far from it ! Most commonly pitfalls found in real business applications are not handled in this sample (well, it's a sample, not an application :) ).

We're achieving to port our client/server based solution to the RIA way. Much assumed knowledge must be revisited, because of stateless mode, limited DSP communication (static scope), and so on. But with a good preparation, with a toolbox to ease DSP development, and a revision (and simplification) of existing transactions, it's possible.

I'm not sure a CRUD approch is right for a well established application to be ported. Most of your model accesses should be done via business rules (more elaborated than CRUD).

this's my vision on how to get into the Uniface RIA :)

Best regards,
Richard

thanks ;-)

I have not had a look at USP for a while... but when I get the time I will go back to them. 

[[Media:2360778]]

There u go, Osie :)

Sorry the pic is in - RIA screen shot  1.jpg... could not figure out how to link it in...

... erhmm ... can't see anything :) They seen be have gone somewhere. Try to upload it to the screenshots (MATERIALS) in the forum. Guess, that will solve it.

As promised.. here is a screen shot that I have been playing with .. if the link works

the pic is in - RIA screen shot  1.jpg... actually I could have done about 8 screens in the time to write this email :-D

It uses the MUSICSHOP  code to produce a CRUD on any entity I want.

It comprises of

a dynamic tab generator (done via defines) such that you get a tab for each entity you want CRUD functionality for.

-- The bits at the top of the screen Drinks, Food, Rooms etc which automatically run the correct DSP's.

2 DSP templates which autogenerate the list screen, and detail screen

-- The list screen is a dropdown list, search keyword function, paging, and sort buttons for all visable fields... exactly same functionlity as musicshop but generated dynamically

-- The detail screen is a basic template which I then do a load all fields with.

-- All labels are automatically inserted via messages and are language sensitive

The conculsion is that for each new entity I want it takes about 5mins to add a new tab, generate the fully functional list screen and detail screen.  The most labourous task is the matching generic template field for component enttiy field.

In the time it took to write this email I could have done 4 more screens :-O

n.b. I am not sure of the pro/cons but I found the only way to have the list and detail screens to work together was to set them as state management components.

osie

Good Morning from here,

it is pleasend to read, that you found your way through my tutorials. I saw you online working on it ;)

Right now, I'm preparing Part 4 of the Uniface frontend templating series, which again will take uDict as example and extend the Uniface Entity Explorer a bit with multiple outputs. But that's still work in Progress as well as the "GHANIFIED! Javascript ToolKit v0.3" with a bucket full of enhancements and new stuff.

Did you miss something here or there?! How could I improve this from your point of view?

Cheers,

-GHAN-

Hi Ghan

Really nice tutorials... I went from html basics to your entity server... all worked perfectly... Now, it is time to look at it a bit more indepth.

Very surprising how easy it was to call a usp/dsp from the web.

I am still keeping my options open whether to go usp or dsp... but I have now some insight into usp's too.

Thanks

osie

Well ... you don't need to start at STAGE 2 ;) ... if you would like get more information about, whats happening with Uniface and web, then you might want to follow the tutorials of mine. That should get LEVEL 1 ... this opens up for the things that happen behind (any) scene- no matter if it is USP or DSP. Depending on how far you want to go, you can continue to look for further examples and tutorials. Free for everybody, of course.

And if you need a place to make your experiences documentated, be welcome :) Rafael did so and my stuff is there aswell ... Copy'n Paste + compililation will give you a taste :)

Always remember: It's only TEXT that will be produced within Uniface! Nothing more and nothing less.

For myself I even build my development tools in web interfaces. The Example of the Entity explorer is used here to generate HTML Templates (or in Uniface words: Skeletons).

[[Media:2354283]]

Other examples to be mentioned are surely the Message Searcher Form which is done with a USP (Screenshot). This makes it fast to find, whaever you are searching for. Last but not least comes the thing our customers love the most: The LookUp widget!

[[Media:2354284 right]]

Only one USP is used to serve 34 combinations of totally individual LookUps. This could be compared to a DSPcontainer reused application wide. Its very fast and uses normal uniface retrieves to do its job! The small blue glyph above the LookUp indicates the feature on the field.

So many possibilities and so much to do ;) ... The used framework is capable of letting the customer add or remove fields without to compile stuff. They can have their own layout on the system as it isn't bound to the code. Finally look at my last image. It showes a slide from CU2008. We have solved any of these problems and are still moving. Stateless, with diconnected datasets, browser INDEPENDEND and reusing the existing code. One point is actually missing on that slide: Beeing capable to hold the control on all those technologies/languages in order to deliverd a perfect support for the customer! Guess I don't need to mention that, right? ( [x] Solved )

[[Media:2354285]]

Did I get your attention and interest? ...  ;) There is much more to explore than an out-of-the-box CRUD-feature. Let me show you!

Hi Ghan

I have already read lots of your writings on AJAX(cool listbox, normally only able to be done by a unifield), javascript, and USP's.  I know of your stance on USP's.  I think it is all a bit too detailed at present for me.  It is stage 2.

For me, I need to start somewhere having been shelterd for so long by the world of web due to the uniface technology and applications that have not needed it.  I imagine this is the same for much of the uniface world at present.  However, I think now is the time, with the involvement of uniface and RIA, to do some 'hello world' coding.  For me, there was an unexplored world out there of web servers, server aplets, PHP, javascripts, ajax etc etc.

Due to the push of DSP's by uniface I have gone this route.  Similarly, as tomcat comes with uniface I use that.  I look forward to the time when I can reassess my options.

At the moment it is what can a DSP do with pure uniface.  When I hit a brick wall I hope I will have enough knowledge to deviate.

I will post some pics soon...

Thanks

osie

You wrote:

"I would have thought everybody would have already converted parts of their application to web.. if only out of interest."

I can't speak for the others, but actually we have! ...and not only out of interest! The acceptance to web IS growing and so our application gets more and more service orientated. This enables us to reuse the code and stay at a max efficiency, no matter what frontend is needed. But to disappoint you I need to mention, that our web is performed by USPs instead of DSPs.

Web isn't out of the box ... web is morphing! And you need to stay flexible with YOUR web and often go for new ways- maybe every time! I understand the DSPs to be very complex and demanding time to figure on how to use this construct. Maybe this is the reason for the silence while talking DSPs ... :)

Good luck to you with the DSPs. Maybe you post some screenshots of you work and features!?

-GHAN-