Tracking Omnis

Rob Mostyn mostyn at platformis.net
Tue Feb 22 10:02:52 UTC 2022


Thanks Doug,
I’ll look into that.
Rob

> On 22 Feb 2022, at 03:23, Doug Easterbrook via omnisdev-en <omnisdev-en at lists.omnis-dev.com> wrote:
> 
> hi rob:
> 
> I wondered where this got to …
> 
> 
> regarding: 
> 
>> In terms of presenting the bootstrap HTML, it doesn’t work.  At least not yet.  The content appears but the elegant bootstrap presentation is hampered somehow.  I wonder if it has anything to do with Omnis’ absolute positioning in the browser (the handling of different widths within the remote form) v. the pseudo distinct oBrowser object.  The rendering is pretty awful.  Tolerable though for my needs.
> 
> if you are serving things up through 127.0.0.1 or what have you and/or the bootstrap CDN is not available to you or at a different path name, you will only see the text version.
> 
> we see that too if I ask to view a page in obrowser that  has references to the bootstrap CSS a different origin .
> 
> 
> There are things you need to set in the studio/config.json file to tell obrowser to not care about cross site stuff — the CEF switches.  it is documented online .. and to tell the truth… I haven’t gone to explore it fully..   I am told that one of more of these might work
> 
>  "cefSwitches": [
>            "allow-universal-access-from-files",
>            "allow-insecure-localhost"
>            "allow-loopback-in-peer-connection",
>            "allow-running-insecure-content"
>        ],
> 
> 
> 
> 
> 
> Doug Easterbrook
> Arts Management Systems Ltd.
> mailto:doug at artsman.com
> http://www.artsman.com
> Phone (403) 650-1978
> 
>> On February 21, 2022, at 3:59 PM, Rob Mostyn <mostyn at platformis.net> wrote:
>> 
>> Haha… this thread should be called Tricking Omnis !
>> 
>> I just want to close this thread tidily.  Thank you everyone for providing help and to Doug who contacted me offline with images to share.
>> 
>> I was at the point of doing a proper job of installing Apache locally and the Omnis module etc and then Graham Stevens made a suggestion that made sense technically:  the ultra thin app is based on a remote task so why not create a sub class from this and use it as the design task for the remote form.  With the overridden $construct I was in complete control.
>> 
>> The work done meant re-jigging the $construct so that instead of the task being one that existed for the preparation of a single page of HTML (typically 0.2 seconds), that it remained in existence.  The remote form has controls that allow me to select the page, the account and the language and then I click the “render” button.  That action calls methods in the remote task that do what I want it to do and the HTML that is returned is assigned to the $html attribute of the oBrowser object within the remote form.
>> 
>> And it worked!  Sort of anyway.
>> 
>> My motivation for doing this is the rather complex workflow we are establishing within the web app and the way the content changes for a myriad of stages a user may find themselves in when they progress through our workflow.  In this regard this experiment has worked, so my most important aim has been fulfilled.
>> 
>> In terms of presenting the bootstrap HTML, it doesn’t work.  At least not yet.  The content appears but the elegant bootstrap presentation is hampered somehow.  I wonder if it has anything to do with Omnis’ absolute positioning in the browser (the handling of different widths within the remote form) v. the pseudo distinct oBrowser object.  The rendering is pretty awful.  Tolerable though for my needs.
>> 
>> The other issue remaining is that even though I have my selection controls at the top of the form and the oBrowser object below the controls, when the page renders the controls of the remote form disappear and is obliterated by the oBrowser object.   I have to refresh the page each time I want to select.  When the whole process happens slowly on Firefox I can see the HTML text display unformatted initially (without the css being used) and when the css does get used the oBrowser assumes all real estate.  Any ideas on how to control this?
>> 
>> I am not recommending this technique for general use but at some level, it does work.
>> 
>> Thanks to all,
>> Rob
>> 
>>> On 14 Feb 2022, at 15:22, malkishtini at gmail.com wrote:
>>> 
>>> But if you are trying to test the form from an Omnis runtime fact client, then yes, in this case you need to setup the web app on a web server (IIS or Apache).
>>> 
>>> Regards,
>>> Mayada
>>> -----Original Message-----
>>> From: malkishtini at gmail.com <malkishtini at gmail.com> 
>>> Sent: Monday, February 14, 2022 9:20 AM
>>> To: 'OmnisDev List - English' <omnisdev-en at lists.omnis-dev.com>
>>> Subject: RE: Tracking Omnis
>>> 
>>> Hi Rob,
>>> I run JSClinet using oBrowser in a fat client window. 
>>> I just had to set the designtaskname for the remote form to the remote task (which in my case is in a separate lib), then I'm able to run the fat client window and launch the form in oBrowser without running it from IIS or Apache. 
>>> 
>>> Have you tried running your remote form by itself in design mode (ctrl/t or right client > test form)? Once you get that working, I think you should be good to run it from oBrowser (at least that what I do when I need to test a form).
>>> 
>>> HTH,
>>> Mayada
>>> 
>>> -----Original Message-----
>>> From: omnisdev-en <omnisdev-en-bounces at lists.omnis-dev.com> On Behalf Of Rob Mostyn
>>> Sent: Monday, February 14, 2022 5:25 AM
>>> To: OmnisDev List - English <omnisdev-en at lists.omnis-dev.com>
>>> Subject: Re: Tracking Omnis
>>> 
>>> Hi All,
>>> 
>>> I’m just trying to make a shortcut so I can see how web pages look from the fat client window.
>>> I will probably have to install Apache on my machine and go through apache.  I’m probably just trying to be lazy.  I think the remote task is designed to only be invoked from outside Omnis (e.g. Apache, nginx etc) and I’m just trying to circumvent the intermediary.
>>> 
>>> I need to go through the remote task because that has some business logic as well as the page generation.
>>> I was hoping there would be some hack someone has figured out.  I suspect there is no shortcut here.
>>> 
>>> Rob
>>> Rob Mostyn
>>> mostyn at platformis.net
>>> 
>>> +44 (0)20 3233 0044
>>> 
>>> As Carl Sagan once said:
>>> One of the great commandments of science is, "Mistrust arguments from authority." ... Too many such arguments have proved too painfully wrong. Authorities must prove their contentions like everybody else.
>>> 
>>>> On 14 Feb 2022, at 10:28, Phil (OmnisList) <phil at pgpotter.co.uk> wrote:
>>>> 
>>>> Hi Rob,
>>>> 
>>>> Omnis seems to think, what appears to be a remote task, is a remote form, and is looking for the remote task to link with it...
>>>> I don't think that could work with an ultra thin solution?
>>>> 
>>>> Seems you need to just open a specially crafted web page, that will act like the ultra thin form, but I guess does not need the login, or has it incorporated within it, or needs a bunch of settings to open the specific page you are hoping to display in oBrowser...
>>>> 
>>>> Or failing that, just open the same login page as a user would have in oBrowser?
>>>> 
>>>> regards
>>>> Phil Potter
>>>> Based in Chester in the UK.
>>>> 
>>>> On 14/02/2022 00:19, Rob Mostyn wrote:
>>>>> Hi $All,
>>>>> 
>>>>> I have a conundrum… We have an ultra thin web app which has been working well for years.
>>>>> As our web app requirements have evolved and become more sophisticated, the complexity of the code has become greater.
>>>>> 
>>>>> The content of web pages is managed through a window in a fat client app (same library opened in different contexts).
>>>>> 
>>>>> What I want to do is from the window class instance to kick off a remote task that will run the desired web object and return the page content back to the window to be displayed in an oBrowser window so I can see the result.  I created a remote task, subclassed from the remote task in the web app and then I try to to this:
>>>>> 
>>>>> Do $classes.rtPageDisplayTest.$open()
>>>>> 
>>>>> When I do this I get the error message:
>>>>> To use a remote form class, you must set the design task of the 
>>>>> remote form class to a remote task
>>>>> 
>>>>> $open is not a method normally available to the remote task but when it is typed in, Omnis syntactically resolves it and applies the coda-chroming to suggest it is a legal statement.
>>>>> 
>>>>> This message does not surprise me.  I am trying to open a remote task from a regular task and I know I am “breaking the rules”.  Has anyone figured out a way to trick Omnis in doing this?
>>>>> 
>>>>> TIA,
>>>>> Rob Mostyn
>>>> _____________________________________________________________
>>>> Manage your list subscriptions at https://lists.omnis-dev.com Start a 
>>>> new message -> mailto:omnisdev-en at lists.omnis-dev.com
>>> 
>>> _____________________________________________________________
>>> Manage your list subscriptions at https://lists.omnis-dev.com Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com 
>>> 
>>> _____________________________________________________________
>>> Manage your list subscriptions at https://lists.omnis-dev.com
>>> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com 
>> 
>> _____________________________________________________________
>> Manage your list subscriptions at https://lists.omnis-dev.com
>> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com 
> 
> _____________________________________________________________
> Manage your list subscriptions at https://lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com 



More information about the omnisdev-en mailing list