RE: Re-2: Achieving one code base with forms and windows
Thank you very much Lars for sharing your project.
I downloaded it successfully and I will study it when I have some time..
Do you have notes or readme file to learn how to run the project?
From: omnisdev-en [mailto:email@example.com] On Behalf Of Lars Schärer
Sent: Wednesday, February 07, 2018 6:50 PM
Subject: 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:
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
> be 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
> make the code easier, otherwise I know I can call tables and objects
> without 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.