UI tools in xMII 12.X

[Former Member]

Dear Experts,

I understand that there are various UI tools in xMII 12.x such as Dynamic page creator (HTML based) and Object Page generator (applet). If these tools are wizard based, in which instances you need HTML or Javascript to modify the UI screens.

Any limitations with out of the box UI tools. Can you please let me know the required skill for UI developer for xMII.

Thanks

-Bharath

[Former Member · Accepted solution]

Hi

You can go through this thread:

https://forums.sdn.sap.com/click.jspa?searchID=24334134&messageID=6703093

Hope this may help you.

Thanks

[Former Member · Accepted solution]

Thanks Manisha. That is helpful information and gives me the list of UI tools that can be used build UI for xMII. But I am would like to know why the out of the box xMII UI tools are not sufficient.

Thanks again,

-Bharath

[jcgood25 · Accepted solution]

Who said the UI tools in MII are not sufficient? All tools have limitations (MII included) and can only do what they are developed to do, but as history has shown, application developer feature or capability ignorance or other learning on the job related issues creep into the scope of a project, and blaming the s/w is easy to do...

I would not call the Dynamic Page Generator (DPG) or Object Page Generator a UI tool, but more so a simple applet page rendering tool. You can also 'Test' a display template within the Workbench, as long as a query template has been mapped into it, which essentially behaves like the DPG, but eliminates the browsing steps to the two object necessary for the applet.

The other thread referenced above showcases how extensible MII can be and additonal ways to capitalize on the Data and Business Logic Services of MII. The additional html editing s/w packages mentioned provide WYSIWYG tools for people less experienced in developing HTML in a text editor environment.

HTML is the web page container for applets and contextual elements delivered by MII, and aside from basic html related javascript functions, javascript is used to 'talk' to the applets on the client side. Applets have events that trigger a javascript function that 'does something'.

Regards,

Jeremy

[Former Member · Accepted solution]

Thanks Jeremy. We want to keep xMII as pure as possible for now and want to use the out of box xMII's UI tools/methods and no custom coding.

We don't want to have some HTML or javascript to glue together some applets as our strategy is avoid custom coding.

Thanks again...

[jcgood25 · Accepted solution]

A bit surprising considering the SI partner you work for, but if that truly is your strategy then you are not going to be able to unleash the power of MII in the hands of your users. The iGrid has some basic built-in user capabilities, whereas the iChart and iSPCChart have significantly more.

If your strategy prevents you from incorporating basic html form, table, button, or other elements then you will be limiting the user to applet based data views. Drill downs, navigation, and ad-hoc user interaction fundamentally require javascript since the thin client environment is in the Internet browser / Sun JRE plug in control.

http://www.sap.com/usa/solutions/manufacturing/manufacturing-intelligence-software/index.epx

Without html / javascript to capitalize on all of the integration and intelligence services provided by MII the cost savings and significant ROI conveyed by the customers would not have been possible:

http://www.sap.com/community/pub/events/2007_SERIES_AMS/index.epx

Regards,

Jeremy

[agentry_src · Accepted solution]

Rather unusual strategy with MII.

[Former Member · Accepted solution]

Why is that unusual? I would think reducing the amount of "grunt work" and focusing on "value added" work would always be a good thing...

[agentry_src · Accepted solution]

To Rick:

"We don't want to have some HTML or javascript to glue together some applets as our strategy is avoid custom coding"

I would call this an unusual strategy.

Mike

[Former Member · Accepted solution]

Hi, Mike.

I think not needing "custom code" to link visual components together is a very desirable strategy. It's the approach we're taking with our UI widgets at Burning Sky. The key is to be able to "declaratively" bind relevant context between widgets - work orders, material codes, etc... - and let the events automatically trigger relevant updates in other widgets.

In any case, I think any time you can avoid hand-written scripting for the mundane tasks, but still customize scripting for the exotic, it's a good thing!

Rick

[Former Member]

Bharath,

I believe Javascript, HTML and at least a little bit of SQL is absolutely necessary to leverage MII's possibilities.

I don't think developing HTML and Javascript coding should be considered "getting out of the MII box", since it relies on these to properly function.

Best regards,

Eduardo