Re-2: Achieving one code base with forms and windows
in github.com/Gnomon/REMOTEOBJECTS you see a way to isolate code from window and how to handle the references – check the enhanced notation tree starting with $root, much more like using the fat client.
(github.com/Gnomon/omnis_jsc_widgets PIMP_JSC.lbs rfACTION_VIA_DRIFTING gives an example on how to work with a stack that is not part of the form and that you can use to controll this and other windows.)
Sorry, that the JSON export/import does not yet work as expected, but i guess downloading the lbs will do, till this is fixed.
> I’m wondering if anyone from the list has used MVC design in their JS
> client app! and if so I’m interested to know how you were able to pass the
> references to form from the controller?
I use MVC in our JS client app,
> but I had to change the way the controller communicates with the view/form
> from the way it communicates with the think client/window.
I use same
> controller for both views.
> From: omnisdev-en [mailto:firstname.lastname@example.org] On
> Behalf Of Alex Clay
Sent: Wednesday, February 07, 2018 3:24 PM
> List – English
Subject: Re: Achieving one code base with forms and windows
> Hi Das,
You’re essentially asking if the model-view-controller (MVC)
> design pattern a good idea. Short answer—yes, assuming you like to be
> productive and stay sane.
Here’s a quick walk-through the MVC design:
> explained/ <www.tomdalling.com/blog/software-design/model-view-
In Omnis, the views are your windows, remote forms,
> reports, and even RESTful endpoints (a more advanced topic for another day).
> The model is usually your database or perhaps a remote web service exposed
> through lists and rows. Controllers are usually objects.
For example, a
> window that displays an invoice has a past due warning on it. This is your
> view. The database has a due date. This is the model. The controller’s job
> is to look at the due date compare it to today, and show or hide the past
> due warning.
Putting code on table classes has come up before and is
> hugely useful. Is this a model or a controller? In my opinion, table class
> code is an extension of the model and generally exposes complex behaviors
> and attributes that are derived from the raw data.
Articles about MVC will
> tout the reusability of views, but controllers can also be quite reusable.
> Consider a view of a customer with its own past due warning. Imagine an $
> isPastDue() method on the customer’s table class that queries the invoices
> for this customer and returns kTrue if any past due invoices are found. You
> can use the same controller from the invoice example with the customer view
> and customer table class to manage the past due warning.
And here is where
> object-oriented coding shines. It’s likely your invoice controller and
> customer controller will have different functionality. You can move the
> common code to a “Can Be Due” superclass, which these controllers inherit.
> This lets you identify these controllers as sharing common behavior and
> treat them accordingly.
For example, if you want to send an email summary
> for all past-due items, you could instantiate an instance of all
> controllers that subclass the “Can Be Due” superclass, ask them for their
> past-due items, then put them in an email. In this example, the controller
> become a model, in a sense. Yeah…it’s complex, but very cool. 🙂
> part of your current confusion comes from scope and ownership. This is
> where object references and item references work well. Following strict MVC,
> the view (window) has no idea about the controller (object). In Omnis,
> that means your controller object is instantiated outside the window and
> owned by an external instance to the window. This could be something
> persistent like a task or menu, or another object. The controller object
> would then instantiate the window, or be passed a reference to it by
> whatever code instantiates the object, and off you go.
To be completely
> honest, our code doesn’t follow MVC design exclusively. We have PLENTY of
> code residing directly on windows, generally relating to how that window
> exposes and manipulates data or the user interface. We rely heavily on
> reusable frameworks and superclasses to bring common behaviors to our
> classes. But there is still plenty of MVC going on in our apps. Once you
> learn to recognize it, you’ll see it everywhere.
> On Feb 7, 2018,
> at 13:44, Das Goravani <email@example.com> wrote:
> So to achieve one
> code base while having fat client windows and remote forms that replicate
> each others functionality, one would use Objects and Table Classes to hold
> the code so that it’s not replicated in the form and the window, correct?
> Tables are best for that code which addresses the row or list it is
> related to because one does not have to do extra work to address said row
> or list.
> Object classes are repositories for code
> Once you have
> put your code that would be in the window or form, into
> object and table
> classes, one has very little code left in the window
> and form, just the
> calls to the code in the object and table classes,
> the passing of
> parameters too
> I think all of the above is correct. Is that correct?
> My question then is, I have heard someone knowledgable say that they
> instantiate their object classes into the form and window. Would this
> to make calling into the object easier since it’s then an instance
> variable of the window? (I’m really out of my knowledge base now,
> completely unsure what I’m saying)
> How do you get the code you wrote
> in an object into an instance
> variable, is it by subbing it to the
> object you put code in… I’m not
> sure what subtype really does when it’s
> an object with code in it
> I want to move windows I have created (fat
> client windows) into being
> forms for iPads
> I have the windows done
> and working great.
> Now do I move the code to Tables and Objects for
> their respective qualities, make sure it all works, have to add ref’s and
> such things…then create my form replicating my window say, and call the
> code from it as well, with very little code left therefore in the form just
> like very little left in the window.
> Is this the overall idea ? Am
> I onto the path here of “one code base multiple platforms” correctly?
> My only question revolves around an unknown for me and that is what is
> the way to make the coding easiest…is it by putting the object somehow
> into the form and window…see I don’t know what subtype does…or do you
> assign your real object to an instance object…again this is only to
> the code easier, otherwise I know I can call tables and objects
> them being embedded in the window (tables can’t, I get that)
> OK thank
> you in advance,
> Das Goravani
> Manage your list subscriptions at lists.
> omnis-dev.com Start a
> new message -> mailto:firstname.lastname@example.org.