Just as an exercise, why doesn't some developer at PSC take it upon themselves to modernize the Data Dictionary code? Why the heck is it not even resizable? It looks like something from V7.
I'd like to see some investment there as well. While there may be some DB niceties in PDSOE, it's not a deployment product; we don't use it at client sites. As for OEE/OEM, I only use it when I have to, i.e. on a Windows back-end. So for Unix schema maintenance, it's the CHUI data dictionary. Using it to view a Detailed Table report, five lines at a time, is like viewing the ocean through a porthole. Possible, but not satisfactory.
(Our fireworks were on the 1st. :))
Fireworks won't e for another 9 hours yet, unless you count the one's last night.
I've only used the DB Navigator perspective for reading the dictionary. I see that one can right click and add things, but it still isn't a great interface. Moreover, in many case, certainly the present one, I have three DBs in play - an empty one, an active one, and a saved one. Schema changes are made in the empty one which is never attached to PDSOE. This is then copied to make a new active one and some operations will occur on it. When I am testing a new or revised stage in the processing, I will do all steps up to the target and then make a copy so that I can make multiple restarts on that level in testing the new stage. Only the active one is ever attached to PDSOE.
It just seems like there is an opportunity for a feature rich tool with lots of functionality which illustrates what the product is capable of doing ... instead of being embarrassing like the current version.
Repeat for year = 1995 to 2095:
put unformatted idea: community.progress.com/.../next_gen_database.aspx (new options).
if no reactions: fire managers.
end.
Adding functionality to the database is good too, but I understand that some of it is a non-trivial amount of work. What annoys me about the Data Dictionary is that it is a trivial amount of work for someone experienced with the tools.
“What annoys me about the Data Dictionary is that it is a trivial amount of work for someone experienced with the tools.”
If all that is done is to make it resizeable, that is a tiny part of what I am suggesting.
Moreover, the point is that something nice should come from PSC, not be buried in a whole bunch of other stuff which I have no interest in.
Thread created by Thomas Mercer-HurshJust as an exercise, why doesn't some developer at PSC take it upon themselves to modernize the Data Dictionary code? Why the heck is it not even resizable? It looks like something from V7.
Stop receiving emails on this subject.Flag this post as spam/abuse.
Well, depends on the UI of what. PDSOE certainly doesn't look like the V3 procedure editor. To be sure, the procedure editor could use a facelift too, but I don't see it very often anymore. I suppose there is a limit to just how "modern" one can make a ChUI tool, but that is no reason for the GUI tools to stay in the dark ages.
As Rob pointed out, the ChUI dictionary is the only one that counts.
It was a bad choice to lay it out for 80x24 screens back in 1985 (even then 132 x 48 was my standard development configuration) and it is ridiculous to look at it now. Nobody has tiny little monitors any more. You would be hard pressed to find one in a museum and if you did find one the chances of it actually working, should you find a port to plug it into and turn it on, are slim. And if you have a handful of 4k monitors on your desk looking at 5 lines and 3 columns of "detail" at a time, with no capability to resize it is not just a bad choice of "conservative defaults" it is more like fingernails on a chalkboard.
So yes, I agree, it would be a great project for someone to apply some improvements to the DD UI.
I disagree that the ChUI one is the only one that counts. Some investment in the ChUI one is certainly justified, but there is also a limit to what one can do. There are lots of possible uses for the GUI one independent of PDSOE and it really should be an exemplar, not an embarrassment. No reason not to use the GUI one to maintain a DB on a Linux platform using -S and -H either.
ChUI is the one that works on all platforms. I really don't see any need for a specialized single-platform solution.
Connecting remotely is ugly and slow and if the point is to use a mouse because... mouse!, well, you've missed the point.
Furthermore I have zero desire to install *anything* on MS-Windows. Ever. None. Zero. Zip. Nada. Reducing the number of reasons to have MS-Windows around is my goal. I am on the MS-Windows eradication bandwagon -- taking a step backwards is not part of the program.
Speaking of the difficulty of modernizing ChUI dinosaurs ...
Regardless of your personal issues, the fact of the matter is that Windows with PDSOE is the primary development platform so having a good Data Dictionary tool on Windows is expected.
> Windows with PDSOE is the primary development platform...
That's a bold proclamation. Got any evidence to support it?
An improved data dictionary tool is definitely a good thing. And I'm perfectly ok with that being a by-product of generally fixing it on all platforms. I'll agree to hold my nose and ignore MS-Windows silliness so long as ChUI isn't ignored.
I am not ok with the idea that it should only be fixed for Windows. You shouldn't be either -- that kind of thinking really ought to be anathema to someone who espouses the sorts of architectural purity that you favor.
I'm not advocating only fixing for Window, but I am also aware that there are limits to what one can do in the ChUI interface.
> No reason not to use the GUI one to maintain a DB on a Linux platform using -S and -H either.
I disagree. When I deploy a Linux-only application with AppServers and batch clients running server-side, I don't configure my 4GL broker to allow remote connections. And I'm not going to do that just for schema maintenance. And if I wanted to do that after the fact, it could take weeks (and security approvals, and change-management tickets, and solution-design diagram revisions, and pushing firewall rules, etc. etc.) to do that in a financial services production environment. No thanks.
Customers (smart ones, anyway) have embraced the principle of least privilege. It's no longer a case of "give me a range of 100 ports to work with because that's the WebSpeed default". The act of opening ports on a server has to be justified and auditor-approved. "I want to use a GUI instead of a CHUI" is a flimsy justification.
I'm all for refreshing Progress utilities and tools across the board, both in modernizing the look and feel and in improving functionality and workflow. After all, app vendors are judged by association based on the platforms we use and the companies we partner with. So if the GUI dictionary also gets a polish job, great. But I deploy cross-platform, and when I work on the DB I want to do it on the DB server, if at all possible. So CHUI is my primary environment for admin work. And as Tom said, using CHUI makes it easier to make tools and snippets that you write once and run everywhere.
I have no problem with you're wanting to do ChUI. I just think there is a limited amount of modernization of the UI. Some functional things, yes. Some UI like resizability. But, there is only so much one can do with ChUI.
I just had a "wonderful" example of a structural improvement. I have spent the better part of the day off and on making a sweeping set of changes related to my other post community.progress.com/.../67387.aspx Very tedious work. On the next to the last file, I accidentally deleted the table instead of the index. Well, Ctrl-Z to undo seems like a good idea ... only it undid everything I did today. Seems like questionable transaction scoping.
I gave up on both UIs long ago and just wrote a program to consume a spreadsheet.
Same thing for the reports. I have my own tools for most of that stuff.
It would be nice for Progress to update both of them but I suspect our best hope would be something web based using Telerik controls.
[collapse] From: TheMadDBA Sent: Saturday, July 4, 2015 17:54 To: TU.OE.Development@community.progress.com Reply To: TU.OE.Development@community.progress.com Subject: RE: [Technical Users - OE Development] Data Dictionary |
I gave up on both UIs long ago and just wrote a program to consume a spreadsheet.
Same thing for the reports. I have my own tools for most of that stuff.
It would be nice for Progress to update both of them but I suspect our best hope would be something web based using Telerik controls.
Flag this post as spam/abuse.
Among the things which needs help is the reporting. Print to the printer and there's no margin so, if one three hole punches it, the holes are in the text. Print it to file and it loses the form feeds. This isn't hard, folks. Yes, I know there are other programs, but shouldn't the standard one be reasonable?
I have recreated the work I did yesterday by editing a .df. While crude and error prone, it was actually faster than using the Dictionary itself and there were things I caught that way which I wouldn't catch the other way. I like the idea of a web-based interface and the potential for using the hyperlinks and real-estate for clear presentation and good editing capabilities.
I would be happy with a web interface
Jeff, that is really only of interest in the context if you are going to contribute the code to PSC since my issue here is with the tool which PSC delivers with its product.
Back when the source code was released as PSDN, we could have done this ourselves. But you're absolutely right about Progress supplying an updated one. Really, there is host of dialog boxes and windows in the WIndows development environment (pre-PDSOE) that are frustratingly small and non-resizable.
These days the source code IS available on Progress Communities….