Table and Query Classes good or unnecessary?
On Tue, Mar 20, 2018 at 7:24 AM, Marten Verhoeven <email@example.com>
> Hi Clifford,
> I Like endings because it is more obvious where things belong to. And even
> with endings, code folding or vertical indentation lines this can still be
> the hardest part of readability (structuring your code differently helps
> best when possible). The most common style used for lisp I find hard to
> read as well:
> (if (= x 10)
> I structure it differently:
> (if (= x 10)
> );end if
> I really noticed I make fewer errors this way. I can see instantly where
> blocks of code belong to without having to put my cursor on the parentheses
> to see. Things become really unreadable when nesting, pretty quickly. So
> for me, some part of it is just getting used to, some part is not. I just
> find it nicer if I can see immediately where the block of code ends and
> that I don’t need to follow the flow of the code to find it.
> > Which is why I used PyQt. That more closely approximates native widgets,
> certainly more accurately
> > than Omnis. Omnis never looks quite native either and it’s
> understandable given that it paints its own
> > widgets on a canvas.
> You might be able to build software for windows with this, which feels
> like any other application, but does it have good RAD tools? How fast is it
> to build your screens? I bet it takes a lot more time than building (and
> changing) it with Omnis.
See for yourself. <projects.skylogic.ca/b
remember really liking the “springy” layouts of PyQt. I don’t find the
ability to drag/drop widgets onto a form all that big a deal. That isn’t
where the heavy lifting is in building an application.
> And by no means am I calling Omnis a good native ui tool. The problem with
> Omnis is that it hasn’t progressed enough. Omnis never was _the_ tool to
> build great looking interfaces. It always has been a tool to build decent,
> not to complex, user interfaces, but build them really quickly. Same goes
> for Omnis, the language: This has always been the least feature complete
> language I know (no constants in 2018?!), and always has been strange, has
> quite a few strange edge cases, etc. But, because of its simplicity, you
> are forced to write more simple code, which is therefor easier to maintain.
> It is not suitable to build your complex hashing algorithm, but for
> business logic and basic platform structure it is very capable and _very
> fast to develop in
> _. I can’t stress that enough. Being able to use other tools as well is
> not in question. But how fast can you build stuff with it. When comparing
> to Omnis, that is the most important question.
Speed to market is important, to a point. There are other criteria that are
important, too. A non-exhaustive list would be:
* great documentation and a wealth of resources in terms of articles,
blogs, code samples, benchmarks, best practices, Stack Overflow posts,
* a developer community that is large enough that chances are high there
are hundreds if not thousands of people have already dealt with the very
same issue that you are now dealing with,
* open source,
* a clear path for the future,
* a high enough level of abstraction so that you don’t have to write the
same boring code repeatedly,
* support for a wide variety of databases (SQL, NoSQL, graph),
* support for building realtime applications. (WebSockets, e.g.)
Who cares if you can build stuff quickly with a particular tool if it
cannot do the things you want?
> > Why bother with two completely different languages and two completely
> different codebases to target
> > iOS and Android? Isn’t Xamarin good enough to target both? React Native
> and Flutter are two other
> > frameworks that do a great job building native iOS and Android apps.
> I am in a luxury position: We only use the software ourselves and we have
> standardized on iOS. So I can build the mobile client in Xamarin or Swift,
> it doesn’t matter, as long as it runs on iOS.
Swift is the obvious choice then. Everything I’ve read about Xamarin makes
we want to avoid it. For example: <deanchalk.com/why-im-
giving-up-everything-for-flutter-eea87464599d>. I have been following him
for a while and I trust his opinion.
> I won’t be also creating an android one.
Can you ignore 70% of the market? No doubt, Apple is a big player and they
are not going away but neither is Android.
> And Flutter, really? I would not dare to build anything with it, which I
> intend to keep developing for a long time. It is still beta, and it is
> built by Google.
People have been building stuff with it when it was alpha.
> How often do they really put their weight and vision behind a new thing?
I’m reminded of a couple of quips. 1. About 15 years ago, “Number of Linux
distributions exceeds number of Linux users.” 2. Also around the same time,
“You’re not a real Python developer unless you have released a Python web
> It might as well be abandoned in a few years for the next great thing. And
> even they (the web company) now envision building client UI not with the
> web tools, but with a tool specifically designed for building mobile apps
> instead of being designed in a ‘design by committee’ way as it is with the
> browser eco system (where it is really hard to make foundation changes, so
> many things are just added on top, like typescript).
There is no silver bullet for cross-platform mobile app development. Every
single choice is problematic in its own way. You have to support iOS and
Android and you don’t have the luxury of ignoring one or other? For at
least double the cost in time and money, you can have two native mobile
apps, one in Swift, one in Kotlin. You could also say, “Meh… a web app
that uses WebView is good enough.” Those are the two extremes. In between
those extremes is a continuum of choices, none of them ideal. You have
Ionic, Xamarin, ReactNative, and Flutter. I stumbled across Flutter and
found it easy to grasp and I like Dart. Google made a half-hearted effort
browser but other than some builds of Chrome, that never happened, which is
unfortunate because it is a decent language.
I think Google is envious of the iron grip that Apple has on iOS and looks
at the fragmentation of the Android market and wishes that it could just
start over. Maybe they will. They have a new operating system, Fuchsia,
that they have been working on a few years, that some people speculate
might replace Android and ChromeOS. Google has demonstrated that when they
have full control over the hardware and software, like they did in the
Nexus and Pixel phones, they make excellent phones. Maybe they want to do a
“reset” in mobile. I don’t know. One thing is for sure. They’re not
building Fuchsia OS just for fun. If you own a PixelBook or one of a few
other devices, you can install Fuchsia on that. Apps for Fuchsia are built
using Flutter so if they’re betting big on Fuchsia, they’re betting big on
Flutter. Is there some risk? Sure but I think it’s minimal because in
addition to the Fuchsia angle, Google has been replacing their internal
AdWords applications, amongst others, with Flutter and Dart.
> If the web-stack is so great for cross platform development, why have they
> created Flutter (what an awful name b.t.w.)?
ReactNative is the obvious competitor to Flutter and it’s much more widely
used. It demonstrates that the web stack is viable for cross-platform
mobile development. <facebook.github.io/react-native/showcase.html>
In any cross-platform framework, there has to be be a point of demarcation
between the framework on the native canvas. RN and Flutter take different
approaches and I like Flutter’s approach better. The Flutter team considers
anything under 60 fps a bug.
> I think the web tools will remain useful and used, but I don’t see it as
> _the_ future for building UI.
For applications that require high-performance and high information
density, it’s hard to beat native desktop applications at the moment. That
does not mean that the browser could not become the ubiquitous runtime
engine and that WebAssembly, for example, is what will enable an entirely
new generation of high-performance and high information density
applications that use the keyboard and mouse.
Your comment about the name reminds me of the Dillon/Edwards Investments
Saturday Night Live skit <snltranscripts.jt.org/99/99adillon.phtml>.
I wish I could find the video online.
> > As for transpilation being a bad idea, the facts don’t bear out that
> opinion. We transpile TypeScript to
> > ES 5 so that it can run in a browser.
> I think transpiling can be useful in some cases. Typescript is not a
> there are a lot more problems with debugging, setting breakpoints etc. You
> would never design a language that way if you could help it. So yes, it can
> be done and the enhancements of the language outweigh the downsides in
> debugging, but you would want both (and probably even a different language
> all together).
> But transpiling a completely different language just adds problems and
> edge cases and makes the language behave differently. Clojurescript does
> behave differently than clojure. You use transpiling because it is closest
> to wat you want, not because it is a good idea in and of itself. So
> therefor I think transpiling is a bad idea and you should try to prevent
> can understand transpiling, but that is the only reason.
> > By the way, we have received nothing but great reviews from our
> customers who are using the
> > formerly Omnis fat-client window that we deliver as web forms via the
> Chromium Embedded
> > Framework XCOMP that we’ve built. They actually prefer it to the legacy
> Omnis fat-client
> > windows that the web forms are replacing. One of our design goals was to
> minimize the changes to
> > the user interface while still freshening it up. The UI of the legacy
> fat-client application was hideous
> > not just because Omnis widgets have a sort of Windows 95 look about
> them, at least in Studio 4.3,
> > but because there were some strange design choices that were made at the
> time that the application
> > was built, like pale green backgrounds on all dropdown lists.
> > It doesn’t matter why that choice was made. That’s what the users are
> now used to. We faithfully
> > reproduced those warts in the web application not because we’re not
> capable of changing but
> > because we don’t want any user complaints about “Hey! You’ve changed
> everything!” We will evolve
> > this application over time so that it looks better. It already looks
> much better by virtue of Bootstrap 3
> > styling and Font Awesome icons. We took care to use iconography that is
> as close as possible to the
> > Omnis icons except they don’t look like a SEGA game console graphics.
> I sure hope they love it, otherwise it would be a waste of time:-). That
> omnis widget still look like windows 95 is because you are still using 4.3
> If you don’t build a new iOS with the new toolset of Apple, your
> application still looks like iOS 5, with a iOS 5 keyboard for example. And
> SEGA game console graphics? Really? What icons are you using? Icons are
> just bitmaps. If you have ugly icons, it is your fault, not of omnis.
Stock Omnis icons, which is the problem. Omnis icons have never been all
that great even in their day. There is a characteristic look and feel about
Omnis applications that always made them look a bit off even if they were
excellent and if they weren’t, they looked positively hideous.
> Yes, you can build nicer user interfaces with web tools than current omnis
> (transparency, overlay, animation), but it takes a lot more effort.
Not really. CSS is amazing for doing this sort of thing. The fact is, we
can do it. We’re not constrained by the toolkit.
> An honest question: how long did it take your team to get where you are?
> (Building the middle tier in Python and building a web ui which can replace
> omnis?) How big was your Omnis application? (lines of code, how many
> windows, etc.)
The Omnis application has many person years of effort. It is a very complex
application that has more than 700 of everything, windows, reports,
database tables. The middle tier is not in Python. It’s StrongLoop, which
is a Node.js framework. The frontend is AngularJS written using TypeScript.
The Python bits are SaltStack, which is used for the self-configuring
virtual machine appliances, Django, which provides the web configuration
forms for the sysadmin to provide things database connection credentials,
network information, etc. The migration project wasn’t just a “get out of
Omnis project”. We were also getting certified for meaningful use and HIPAA
so much of the new code we’ve written has had to do with that. We started
this in early 2014 and we got our certification in September 2016.
The migration process uncovered some systemic issues we had with the
database that we had to correct and I understand the historical reasons for
those systemic issues. This application started out as a native datafile
application in Omnis 7. It got converted at significant cost using an
automated conversion process to Studio. After the conversion to Studio, SQL
Server support was added. There were some design choices that were made to
minimize the amount of rewriting that had to be done to support both the
NDF and SQL Server. Effectively, the application was written to the lowest
common denominator so that means SQL Server in some respects was treated
like a more stable NDF with a better SQL implementation. Again, if you had
the full picture, you’d understand why those decisions were made at the
time they were made. Had I been involved with that process, I might have
made the same decisions so I really can’t fault the decisions they made and
even if I were to fault them, what difference would that make? I have to
deal with what is in front of me, not what happened 20 years ago.
Dealing with those systemic issues took months and it was time well-spent.
Creating the CEF XCOMP to be able to have a mix of Omnis and web windows
within Omnis took another few weeks. Months of effort went into devising
the whole infrastructure for how we were going to deploy, manage, upgrade,
and monitor the web application and SQL Server.
We devised generic report generators, window frameworks, base classes, etc.
All that is lots of investment in time up front for making subsequent bits
that are being migrated out of Omnis easier. It was easily six months of
effort before we converted our first window but much of that had to do with
things that had nothing to do with the technology stack we chose. It had to
do with paying off technical debt that had been accumulated and the
inevitable challenges of evolving an application to a completely different
architecture, regardless of the tech stack, while making the transition
from the old to the new as seamless as possible. If we could burn it all
down and just start from scratch, we’d be done by now but that was not a
viable option for us.
> I don’t have a team of developers. I build a complete ERP system, with cad
> integration, touch screen consoles in the factory, planning, crm, product
> configurator, document management, manufacturing chain integration, etc.
> All done by one developer. If it takes me double the amount of time to
> develop, it is not an option.
> Also: I have never heard users complaining about changing a color.
You’ve never met our users. 🙂
> They only complain if they can’t find their stuff anymore or if you break
> their habits. You can only do that if it has great advantages for _them_. I
> can understand if you keep the new web-windows the same if your application
> still has some old Omnis screens, but I would probably (as I have never
> seen your application, I can’t really judge) change all main windows to all
> new designs, and just graphically update the remaining omnis windows to
> match the new design (colors, styling, etc.)
Sure, we could do that and if the changes are enough that the users start
complaining or the perception is that they need retraining, that opens the
door to potentially evaluating other options. We decided not just for
technical but for sound business reasons to take an evolutionary rather
than a revolutionary approach. It’s a prudent approach that gives us the
option of evolving the application over time. We just have to get out of
Omnis to be unconstrained by the old Omnis windows. We do not want to put
any effort into changing the look and feel of the Omnis application when
that time could be put to better use in the migration effort.
> Four years back I did a big redesign of the application, which made the
> application look completely different (not like a normal windows 2000
> application). With that I also completely changed how you find your stuff.
> This task is done a lot and became much easier and faster (interaction, not
> software). That single new feature prevented that users grumble. They only
> complained a little bit at some small, mostly fixable, interaction design
> bugs. They don’t mind changed colors. And they loved how much faster
> navigation was (and therefor accepted some of the small disadvantages).
> Users only really complain if you didn’t do your job properly (can be
> interaction design, visual design, or communication). If you propose a
> downside (for example: needing to change your habits), you need a much
> bigger upside to compensate. As a developer it is easy to forget that,
> because by the time you have finished, you can’t see the downsides anymore.
> >I think the resistance by developers to deploying their applications
> within a browser due to some
> > imagined benefits of having a native look miss the mark if their
> customers want applications deployed
> > within a browser. We fight our customers at our own peril. Whether there
> is actually any real benefit
> > of running our application on an iPad or not, our customers were oohing
> and aahing over demos being
> > done by our competitors who have web applications so if we don’t meet
> the expectations of our
> > customers, our competitors will. I can see real benefits of running at
> least parts of our application on
> > mobile devices. Initially, that will be via WebView and it will be like
> a web site running on a mobile
> > device. We’ll eventually build native apps for iOS and Android. We’ve
> had that in mind from the outset
> > which is why we implemented a REST API even though we control both the
> frontend and backend.
> It actually surprises me that you don’t have a web based mobile client
> yet, if you have a functional web interface with a matching server.
It’s not possible for the bits that have been converted to a web
application to stand on their own. We still have a dependency on some bits
in Omnis. The web forms and existing Omnis windows are integrated with each
other through a message passing mechanism implemented in the CEF XCOMP.
> How long ago was it that you heard customers requesting to run the
> application in a browser? The last time I heard anybody wanting a web
> interface is a long time ago. They want a mobile app now. Wanting it in a
> browser was only because of deployment (IT) or being able to just use a
> computer from somebody else to get to your stuff. But since everybody now
> has his own computer with them all the time they want to be able to access
> it there. Now, I just need a desktop interface and a mobile interface which
> should both work from anywhere. How it is built doesn’t matter as long as
> it works good. So I can choose how to make the best experience in the least
> amount of time, by picking the best tools, not just what is available for
> browser development.
Nothing we have done precludes us from building a native web app. We may
eventually build one but we have to bust out of the confines of the Omnis
fat-client first. We have a REST API. Whether the frontend is
HTML5/CSS/AngularJS, Flutter, ReactNative, iOS app written in Swift,
Android app written in Kotlin, or some fat-client technology is immaterial
from the perspective of the server. It will return the same responses to
the same requests on end points.
> I used to use a web mail client a lot in addition to outlook. But now it
> is just outlook and the mail app. I never touch a browser mail client
> anymore, because it is less convenient and doesn’t work as nice.
> If web is the right tool for your job, good for you. But I know I cannot
> build the experience I need using those tools, with the resources I have.
> That is why I don’t look at the web-tools for any of my use cases. Because
> of the integrated experience of Omnis (instead of a big stack of separate
> tools) I was able to do a lot. Because Omnis wasn’t managed properly I am
> now hitting some limits I can’t have going into the future. They are really
> moving forward again, and I hope it is in the direction I need. If not I
> have to choose different tools for the long run, but my favourite future is
> with an enhanced Omnis.
More power to you!
+1 647-778-8696 <(647)%20778-8696>
Manage your list subscriptions at lists.omnis-dev.com
Start a new message -> mailto:firstname.lastname@example.org