quote:

By the way, IBI is actually following this thread very carefully and have been watching the forums. They are well aware of the complaints that we are raising and the issues we have presented. This is why 5 of us were able to meet with IBI over this issue at summit, and why I have been in email communication with them in regards to this ever since then. All of the smoke of "Provide us a better solution" is just smoke to try to deflect the situation.

I know about them monitoring this thread, which is why we should be trying to make this a positive request. We work very close with IBI and believe it or not, there are a lot of people that back this request. We only need to come up with a good solution and it will get implemented.

I was at summit as well, wish I would of known about the meeting.

quote:

Originally posted by GavinL:

quote:

By the way, IBI is actually following this thread very carefully and have been watching the forums. They are well aware of the complaints that we are raising and the issues we have presented. This is why 5 of us were able to meet with IBI over this issue at summit, and why I have been in email communication with them in regards to this ever since then. All of the smoke of "Provide us a better solution" is just smoke to try to deflect the situation.

I know about them monitoring this thread, which is why we should be trying to make this a positive request. We work very close with IBI and believe it or not, there are a lot of people that back this request. We only need to come up with a good solution and it will get implemented.

I was at summit as well, wish I would of known about the meeting.

Sorry, I'll try to keep things civil. I was actually supposed to be at that meeting at Summit myself, but I wasn't feeling well that morning so I sadly had to skip it. I am very much hoping for a great solution to be implemented that will make all parties happy. I hope my insights can help this cause. Again, sorry for my blunt comments. I am just that kind of person that doesn't tend to cream coat anything.

The GUI is meant for users who want to be shielded from the complexity of code. Our HTML pages are not just HTML. They are HTML, XML, JavaScript CSS, and DTD and all these things must be correct or the page will not work. We are not allowing manual editing of the pages for this reason and there are many product users who understand this and are fine with it. If you want to write HTML code, then you should not use the GUI. You can invoke an external editor that you associate with HTM files in the Windows operating system and then you can write your own HTML, and JavaScript. We also document the Servlet calls so you can write those too. If there is an issue with external editor, a case should be opened with Support Services. We have tried this and it works fine for us internally. Additionally, other UI's in the product are going to start presenting messages about manual editing.

David Glick: "If you see a need to edit an HTML Canvas file, please open a case and we will add the ability to the GUI."[CLOSED] [over and out] App Studio v8.0.09 will apparently fix a lot of issues

END OF STORY.

David,

I can appreciate that the GUI is meant to be a tool for users that want to be "Shielded" from the code. The problem is that this creates a ceiling for what can be done. With the design of the HTML Canvas, its very difficult to build things within Web Design Best Practices. Relative positioning (where its better then Dev Studio) still has its issue. The canvas wants to force all widths/height as pixels instead of percentages. It makes it very frustrating to constantly re-do things when making minor updates. I've documented and shared with your team instances where when adding an element to the page, other elements are completely resized (My IFRAME for my report went from 100% width to -.4% width). Removing carriage returns from the code so that its harder to read in a text editor (Within or outside of App Studio) is not fair play.

Why when I add a button or input or any element does it need to have inline CSS injected into it? It should flow normally within the flow of the HTML. I shouldn't have to draw my element when I add it. It should add it with the CSS class assigned to it, but nothing inline. Let the normal flow of HTML place it and let me set my min-width/max-width etc as needed. If I decide to enlarge it with the tool, then add my width/height properties inline.

If you are so concerned about those who "Need to be shielded from the dangers of HTML and Coding", Then please add a security control where I as an administrator can ascertain a users skill level. I personally believe that properly managing people at multiple different skill levels is integral to a healthy environment. I have my system organized in a way that will provide things at the simplest level of users to just run a report. Someone who wants to be able to ask questions but not have to learn a tool has a Guided Adhoc Application available to them. My next level of user gets Info Assist and my next Level of user would get Dev Studio. I have no problems with adding another healthy layer to that model by adding or removing access to text within App Studio. But that level of ease already exists in IA. So I'm not sure why I need it again. But if thats what I need to be able to do the things I need, then great.

I know that you have done a lot of work and that you have brought the HTML Canvas to a much better state. This isn't about there not being a large amount of improvement. This about the balance being knocked away from what was a fantastically customizable tool. Now we are having subjective limits being put in the way, unneeded difficulties added, and a large step away from the customizability of WF that has made this product great and a joy to use over the years.

There were a few years where I switched over to Business Objects, and one of my greatest frustrations was an inability to get at the HTML and the code. Now I see WF going the same way, and it worries me, because I am seeing a loss of a great differentiator. One of the things that has made this tool as powerful as it is. There is plenty of room for us to both have the things we want. You don't have to force a side and force away developers for people who don't understand how things work. Balance can be restored.

To paraphrase what Gerry himself said during the Q&A. There will always be a trade off between GUI and text. Sometimes you will Start something in GUI, then move over to the text, then back into the GUI.

The way the tool handles text editing now does not correlate with the statements that Gerry made.

Thanks.

quote:

Originally posted by David Glick:
The GUI is meant for users who want to be shielded from the complexity of code. Our HTML pages are not just HTML. They are HTML, XML, JavaScript CSS, and DTD and all these things must be correct or the page will not work. We are not allowing manual editing of the pages for this reason and there are many product users who understand this and are fine with it. If you want to write HTML code, then you should not use the GUI. You can invoke an external editor that you associate with HTM files in the Windows operating system and then you can write your own HTML, and JavaScript. We also document the Servlet calls so you can write those too. If there is an issue with external editor, a case should be opened with Support Services. We have tried this and it works fine for us internally. Additionally, other UI's in the product are going to start presenting messages about manual editing.

So, David, we can't get to the code we need to (if we want to use your GUI) because you assume that (since a few self-destroying customers couldn't figure it out) we as a whole have no clue how to manage HTML, XML with DTDs, Js or CSS? That sure sits nicely, doesn't it?

I would love to use/rely on the GUI-based tools you provide us, but there are times when I am doing something in HTML Composer that causes some code to be written internally that needs to change, but the internal code remains despite me trying to change it via the GUI and I get stuck. Also, I've ran into at least one control property that fails to work via the GUI. Can't fix it in the code while I wait for your next release because...no access. I also agree with eric.woerle above this post in that we need both text and GUI for a healthy environment. I also commend you in your efforts to enhance the user experience via the GUI tools, but you are making a horrible mistake by taking out the code access.

Since I am stuck using your products for the time being, what external editors would you suggest we use in conjunction with AppStudio? I've heard hit and miss from others on these forums on which ones play nice and do not. What is IBI using?

This message has been edited. Last edited by: CoolGuy,

Francis,

What do you need to do that the GUI does not allow? Your reply does not state what needs to be exposed.

Eric,

There is inline CSS only if you change attributes in the session. If you want to have the CSS external, you can open the CSS file you attach and edit it in the CSS Editor which is part of the product. Percentage positioning is allowed, but not default. You can type percentages. The rootxmlnode is the only section of the file that does not have returns. When Gerry was speaking at the "Ask Gerry Session", he was speaking about FOCUS code.

CoolGuy,

We do not document our XML islands so no one outside of programming knows what they need. Of course anyone can read and write XML, provided they know what is expected and here we all do not.

Please tell me a situation where you want to do something and the UI cannot. Please also tell me where the UI does this coding that needs to change and why.

Only with real cases and reproductions can it be pursued.

Thanks.

quote:

Originally posted by David Glick:
CoolGuy,

We do not document our XML islands so no one outside of programming knows what they need. Of course anyone can read and write XML, provided they know what is expected and here we all do not.

Please tell me a situation where you want to do something and the UI cannot. Please also tell me where the UI does this coding that needs to change and why.

Only with real cases and reproductions can it be pursued.

Thanks.

David,

Fair enough on the XML with DTDs.

"Please tell me a situation where you want to do something and the UI cannot.":
HTML Composer:
- Can't set a task to refresh a single panel within a BI Portal (case opened).
- Can't use the "Selection & Validation" property for controls (case opened).
- Can't set width and height of an iframe to 100% for responsive design without dealing with scroll bars.
- All the insights shared by eric.woerle above.
BIP:
- No page-level collapsible banners for filtering.
- Non-customizable responsive breakpoints (ones present work poorly with lower display resolutions).

"Please also tell me where the UI does this coding that needs to change and why.":
- I can't remember when it happened last and what exactly I was doing, but sometimes I am making a change somewhere in the GUI and then at a later point I try to change that change but the GUI fails to adhere to the new change. I will keep you posted when it eventually happens again! It's kind of similar to what eric.woerle was having issues with above where the GUI changes things w/o your immediate knowledge or decides to do certain tasks in ways you would rather have them done differently. Again, I will make note of my continual frustrations and update you when I get a healthy list accumulated.

Appreciate your time and responses.

This message has been edited. Last edited by: CoolGuy,

David,

I just want to flip the questions here a bit, because there is something that I don't understand...

How is my editing the HTML in an external editor, any different then a text editor being readily available for me in the tool? Your main argument above seems to be (paraphrased) "Some people just can't handle the power of code". But I can make the same mistakes in an external editor as I can in an internal editor. If I anything, it seems I'm more likely to break things when outside the tool where you can't run checks on what I write. How am I better protected by being forced to leave the tool?

CoolGuy,

Your item 1 is not in the product. It would need to be new functionality. Item 2 should work. I'd need to see the case for specifics. Do you have the number? Width and Height of 1005 may product scrollbars at design time, but not at runtime unless the report content does not fit. The report content itself is not responsive. I don't handle BIP, but I will inform that team of those points. When you do have the scenario of code changing, please contact me. Thanks.

Eric,

External Text Editor support is coming from Windows. We cannot stop a user from associating a file extension to a Windows program. However, the same issues apply - if you change something and not all the parts that affect it like the XML island, etc., the page will not work. You will also get the message that the page was manually modified and if you report an issue, we may inform you that the page was manually modified incorrectly and you need to fix your code. It would not be a product issue at that point.

David,

Again, how am I in a better position because its now more difficult for me to do the same things that I'm going to do anyways? At least with using a text editor in App Studio you can run your compiler to alert me of any issues instead of my having to find out the hard way that the xml was given a carriage return in the middle of a word.

quote:

Originally posted by David Glick:
CoolGuy,

Your item 1 is not in the product. It would need to be new functionality. Item 2 should work. I'd need to see the case for specifics. Do you have the number? Width and Height of 1005 may product scrollbars at design time, but not at runtime unless the report content does not fit. The report content itself is not responsive. I don't handle BIP, but I will inform that team of those points. When you do have the scenario of code changing, please contact me. Thanks.

David,

Can we get item 1 added as a NFR?

Item 2's case #: 21193558

Width & height of iframe issue:
Reproduction steps:
- create new HTML page in AppStudio;
- insert empty iframe (no report);
- set iframe's width and height to 100%;
- run;
Scroll bars are present at runtime.

Thank you for letting the BIP team know about my issues with that product piece.

Again, appreciate your timely responses.

David, I don't know that telling developers, if they want to code in HTML, use an external tool is the correct response. Your killing your application by doing that, as there are a lot of developers that write these reports at the code level.

I'd like to know if you have a development background, because there isn't a developer in the world that would be happy with being shielded from the code. Lets ask your developers that write App Studio to do this all through a GUI, without touching code. If they have something they need added, then create a ticket with Microsoft, then see what they say. If your new target is for Business Analysis only, then your on the right track, but once they find they need custom work, which is 90% of everything we do, your back to these types of forum posts. To create a ticket, for everything that we can do via code, that can't be done in App Studio, will only cause 100's of new tickets every day, of which we have to wait many months to get. That is a very unacceptable answer.

By the way, if I use an external tool to change code, can't I mess that up just as bad if you added, "Open in Text Editor"?

I keep starting to compose a reply to David's question, "What do you need to do that the GUI does not allow?", but since it's a leading question and a ridiculous one at that, I close the window without posting. As you can see from the current set of responses, things will start getting rude again - there's no point talking to a brick wall.

When you reboot your Windows PC, you can lose the HTML file type association to the external text editor.

When you receive an email in Microsoft Outlook that contains an HTML file, you cannot double-click the HTML file to open it in Internet Explorer - it opens in the text editor.

Certain text editors have trouble with the temporary file that goes between App Studio and the external text editor and you get a zero-byte file upon saving.

I think Francis has some repressed feelings that he needed to let out. Haha.

Eric,

You are not in a better position. If you want to write your own code, then the GUI is not for you. If you write your own code, then the HTML, JavaScript, etc., is all your creation. Nothing of the GUI is needed - no XML islands etc.

CoolGuy,

I just tried your frame steps and I get no scrollbars for the frame. I believe you want the frame to size for the browser size. To do that, I would set autosize to Yes for the BODY object and then draw the frame which would get "Accept any changes" as its autosize options. The case you stated is fixed in the forthcoming 8105 release.

GavinL,

There are levels of developers. The App Studio UI is not Visual Studio and it is not meant to be. Visual Studio allows users to write code. However, when you design a dialog, you draw the dialog and the code is written for you. Now Microsoft will let you see that code if you want, but good luck trying to modify it since it is constantly rewritten. Same goes here. This is not for someone who wants to write HTML code. That should be done in an external editor. Also, the AS GUI is not meant to be an HTML authoring tool like Dreamweaver. It is means to create HTML pages for using WebFOCUS reports and charts and presenting controls for parameter values. The developers of App Studio HTML canvas only use the GUI to create pages. If there is something you need to do that you believe the GUI cannot, you should open a case.

Is there a way to point the App Studio HTML Composer tool to the latest version of jQuery and jQuery UI - the ones that are used by the whole organization, and not the older one that is used by the App Studio HTML Composer tool?

Does App Studio HTML Composer have a multi-select tree control?

Francis,

WebFOCUS comes with one version of jQuery and since many parts of the product use it, it is the only version certified for use. In the HTML Canvas, you can link in any JS files you like using the Settings panel. However, the version you link in is obviously not tested and may not work properly.

The App Studio HTML Canvas has a tree control that can be set to multiselect or single-select.

David,

I'm not saying that I don't want to use the GUI or that there aren't a number of things that I can take advantage of to lower my development time. I'm saying the most powerful and efficient way for me to be able to work is to move between both as seamlessly as possible. There are ways that can be currently leveraged to restore this balance that his been lost. I'm still at a loss for why we can not have this balance?

I hope that as time goes on, that I will desire to go to code less and less, but there are always things that will be more efficient for me to do in code then in a GUI.

Unfortunately as this conversation goes on, I get the feeling that you are not open to the idea that this is how development works. Considering that we are getting responses as deflections, instead of actual answers. I feel like the basic response is reverting to "Because I said so".

When you rejoined this thread, I had really hoped that we could have truly had an open and honest conversation in which we could move forward in a good direction for everyone involved. But the longer this conversation goes on, the less I feel that this is going to be possible.

Eric,

Please don't feel that way. It is not because I said so. We do not provide the ability to edit our HTML canvas files for the reasons I stated. This was a decision by a group. When users edited the HTML, they would not update all relevant sections because we don't document the XML islands, etc. Then their pages would not work and they would open bugs. Then our programmers would debug and find that the user made their own problems. I'm sure you can see that we cannot have our programmers debugging user errors since then they cannot program new features and fix real product issues.

At the end of the day, we are developers and by telling us to go use another tool to develop our HTML files for WebFOCUS makes it more difficult on us. As stated before, the code App Studio and Dev Studio produces is all smashed together so it's damn near unreadable as is and maybe that was planned for a this reason. I just hope IBI don't find themselves wondering where their clients went after telling them to go somewhere else to do their work.

David,

You stated: "I just tried your frame steps and I get no scrollbars for the frame. I believe you want the frame to size for the browser size. To do that, I would set autosize to Yes for the BODY object and then draw the frame which would get "Accept any changes" as its autosize options. The case you stated is fixed in the forthcoming 8105 release."

I went in and tried the changes you designated and I did get better results without the browser scroll bars. I appreciate it. There was no BODY object, so I assumed you meant the DOCUMENT node. For the DOCUMENT node, under Miscellaneous, I set Autosize Children to Yes. I then went into the iframe and set Autosize options to Accept any changes. After running, I don't get scroll bars anymore, but there is still a gap between the iframe and the browser. It's not a huge deal, but it does still look kind of tacky. But again, thank you for your help in at least getting rid of the scroll bars. Sorry about accidentally misleading you in thinking that they were for the iframe. I didn't even realize that myself. Sad, right?

As for the update on my case, thank you for letting me know that it has been fixed and will be working in 8105.

Also, if you could get my NFR put in for the ability to set up a task to update a specific panel within the BIP I would greatly appreciate that as well. My goal has been to pass filter params to this one .fex housed in a panel on our portal page first before the rest of the content in other panels gets updated/refreshed after filter submission.

Finally, you would make loads of devs/users happy if you would just put the HTML text editor back in. I hope you eventually do so.

Thanks again!

David,

There is middle ground to be found though. You could add a file check into the save functionality. If the xml doesn't parse correctly then don't allow the user to save. you could remove the XML from the editor within App Studio so that users don't adjust it. You could move the code base to utilize JSON instead of xml where the guts of it is in an external file and re-usable. There are plenty of other options that would allow for a middle ground that can both protect IBI from extra calls and allow us the flexibility we desire. I don't understand why this is an all or nothing conversation. Comments like

quote:

You are not in a better position. If you want to write your own code, then the GUI is not for you. If you write your own code, then the HTML, JavaScript, etc., is all your creation. Nothing of the GUI is needed - no XML islands etc.

are not helpful to the conversation because it doesn't allow us to come together. I don't want to only use one way or the other. Each has its strength and I honestly believe that we can find a way to get to a point that allows us to flow between both worlds. I'm not asking for dreamweaver. If I was I would be asking you to add H# tags, P tags, and other common HTML elements. But I understand that this is not the focus of IBI nor am I asking it to be. But I'm also asking that you don't handicap me by forcing me into a box.

CoolGuy and Eric,

I appreciate your being cordial in your responses. Glad the autosize steps are working for you. Eric, you have provided ideas, and they are not easy to implement. Hiding the XML just means users can't touch it, but it would still need to be updated in cases. Changing to something other than XML is a major undertaking. It will be assessed though.

Thanks again for a cordial and pleasant discussion.

David,

Just now I tried to make the corrections you gave me in regards to changing autosize settings in some of our content I've been creating. I tried to move my chart (in an iframe) from its Left: 16px Top: 0px position to a Left: 0px Top: 15px position, save and run it, and it runs with my chart in the original L: 16px T: 0px position. I open it back up to find that my changes did not save in the new positions I assigned the iframe/chart. Perfect example of why it would be nice to still have access to the code. Also: I don't even have to save it. I just move the iframe, hit run, and it still runs in the L:16px T:0px position. The GUI has issues acknowledging and saving user changes. Same deal with that open case on the Selection & Validation property. I keep running into functionality that doesn't work. There have been other similar scenarios.

Again, please take the considerations of eric.woerle to heart and make the code accessible again. eric.woerle has given you several great options to allow for a middle ground to be found.