PDA

View Full Version : Waiting to Test VFP Import



robertjacobs
2013-02-27, 10:37
Hi. There does not seem to be a lot of activity on VFP import testing. I beleive it is mainly due to the fact that many (like myself) are waiting for final documentation on Lianja vs VFP similarities/differences/best strategies to gain a better understanding on what to expect when the importer is as complete as it will get.

Is it fair to say at this time that a day will come when we can import our VFP projects (prgs, forms, reports, class libraries, etc) and know exactly what needs to be done (fixed) to successfully migrate applications to run under Lianja. It is not feasible at this time to consider migration until one can see the final product and all that it offers.

HankFay
2013-02-27, 10:55
Hi Robert,

if you haven't already, I'd suggest you read the latest version of The Lianja Vision (http://www.lianja.com/resources/the-lianja-vision): this lays out what the VFP developer should expect when migrating to Lianja. Especially note the 3rd-to-last paragraph. This is, as I see it, the key to understanding the relationship of Lianja to VFP.

If I were to summarize in concrete terms it would be this: you get to bring your data (wherever it is), your business rules code, and the principles behind your interface. You then recreate the UI to take advantage of the Lianja opportunities to run everywhere, using your data and (with modifications to fit the Lianja way of doing things) and your business rules code.

That isn't to say you can't import your forms, but (if you go back that far <s>) doing so is like continuing to use @say ... get in VFP (which I know has been done). It works, but it's not the way to go forward.

hth,

Hank


Hi. There does not seem to be a lot of activity on VFP import testing. I beleive it is mainly due to the fact that many (like myself) are waiting for final documentation on Lianja vs VFP similarities/differences/best strategies to gain a better understanding on what to expect when the importer is as complete as it will get.

Is it fair to say at this time that a day will come when we can import our VFP projects (prgs, forms, reports, class libraries, etc) and know exactly what needs to be done (fixed) to successfully migrate applications to run under Lianja. It is not feasible at this time to consider migration until one can see the final product and all that it offers.

robertjacobs
2013-02-27, 13:31
Hi Hank

If you review the classes available in Lianja, it just seems like Lianja offers a lot of what VFP is leaving behind. With that being said why can't a smart importer migrate VFP apps more in line with the Lianja vision. I have not yet taken the time to play with Lianja by creating simple apps the Lianja way. Our company is kind of waiting to dive in by first importing and then enhancing our existing apps to take advantage of new opportunities available through Lianja.

barrymavin
2013-02-27, 17:51
Robert, we have been working on the importer as various tickets have been submitted relating to it. Lianja has gone through an exhaustive beta and has been cummunity driven for best part of a year now. The roadmap is clear evidence of that. OTOH everybody has a different idea on what is important to them and as part of the development process we review forum discussions but most importantly tickets that have been submitted and prioritize them.

if all you want to do is run your vfp apps under Lianja and don't really want to take advantage of everything that Lianja offers (including but not limited to commercial support and the ability to use your existing language skills) then you may as well stay with vfp.

Yes the vfp classes are implemented as are the vast majority of the commands and functions.

We have listened to the Lianja development community and priced the products so that they are affordable to ISVs and SMBs.

"The importers don't work properly" is not at all helpfull to either ourselves, yourself nor other developers. Lianja is a community driven development. We are all part if this development process through testing, submitting tickets, asking how to do ths and how to do that, then iterating this process.

So if you are serious about moving forward with Lianja you can get more involved in the Lianja developer community. We do listen, but we have to prioritize development not just jump all over the map.

Many devs want cloud completed, many want mobile completed. We are working on all these in parallel.

Contrary to what you may think, we have your best interests at heart so please be patient as we progress with development. Rome was not built in a day.

lazyfox
2013-03-02, 14:22
if all you want to do is run your vfp apps under Lianja and don't really want to take advantage of everything that Lianja offers (including but not limited to commercial support and the ability to use your existing language skills) then you may as well stay with vfp.
Yes the vfp classes are implemented as are the vast majority of the commands and functions.

The above is true. But there are quite a few shops having code written over ranges from half a man year to multiple man years running in vfp. Currently rewriting those programs would be too costly or wipe small shops out as development occured over more than half a dozen years growing a customer base in need of running maintainance and neccessary changes. Being able to convert from vfp to a platform allowing me to target web and mobile while I still have those already payed programs running is an asset: worth 10% of developer hours of pure dev time for small projects and 3-5% for larger projects. The added degrees of freedom and the rapid development cycle perhaps even faster than in vfp only then can come into play.
For even larger packages (>10**7€) porting the whole enchilada directly after a maintainance release is IMO the only way to go. You write your porting code, get one of the good testers to flush out showstoppers and integrate your ported version partly into the beta cycle - making that a bit more expensive. If you are good, you ask for another full test run after a RC is out of the door by porting the latest source automatically and putting the Lianja version into Sourcecontrol, so that all new maintainance is done in Lianja and the other devs know from the test report that the product port itself is sound. Not going into analysis paralysis and NOT having the whole spec discusions is itself a worthwhile target - from then on you can incrementally advance with consecutive and not too large budget steps without risking oodles of money or sinking the ship.
So while your statement of course has merit (I want the option to leave desktop as well!) with customers not having existing code base I am arguing for Lianja against Servoy, Wavemaker,Xamarin,Phonegap other more established dev environments targeting web and mobile mostly - not as RAD but with a larger user base translated as "safer". Hence my preoccupation with the importers and compatibility - or at least documented differences to be coded around without further thought or discussion. I am fast in coding if I know the reasons and limits - encountering the grey areas costs me time.

lazyfox
2013-03-02, 15:29
If you review the classes available in Lianja, it just seems like Lianja offers a lot of what VFP is leaving behind. With that being said why can't a smart importer migrate VFP apps more in line with the Lianja vision. I have not yet taken the time to play with Lianja by creating simple apps the Lianja way. Our company is kind of waiting to dive in by first importing and then enhancing our existing apps to take advantage of new opportunities available through Lianja.

Strategy makes sense - but IMO you should get more involved. Only way to get a real picture and nudge the process. Just sitting on the side lines and expecting a finished product is unrealistic. Either pay when it is released in money, time gone by and less effort, get somebody to port your stuff then or "pay" now by offering more of your time and effort and better error reports...

barrymavin
2013-03-02, 20:30
I understand all this, its just a matter of development schedule priorities. I am not saying these will not be addressed -- I'm just saying not right now.

Your mention of other products would require us to prepare some competitive analysis material which we have not yet done nor am I repared to get sucked into an argument that compares apples with oranges at this point.

Let me re-iterate what I have already said in other forum posts.

There is nothing in the Lianja engine to prevents it being adjusted for syntactic differences when they are discovered and reported as tickets. There are many undocumented features in VFP, after all its a context sensitive language with an integral database engine. Thats what makes it so useful for business apps.

The good news is; we are not Microsoft; we are an agile team who can respond and react to the community, bugs you report and enhancement requests you make -- quickly and effectively.

As an aside. I wrote Recital which is still in business and will have its 25th anniversary this august. "Safer" cannot be quantified easily, during my time as CEO and developer of Recital I have seen hundreds if not thousands of companies come and go. Our customers rely on us -- and we are still here for them.

Thats exactly what Lianja brings to you, not just the technology but our commitment to you.

lazyfox
2013-03-03, 11:25
Your mention of other products would require us to prepare some competitive analysis material which we have not yet done nor am I repared to get sucked into an argument that compares apples with oranges at this point. ... I wrote Recital which is still in business and will have its 25th anniversary this august. "Safer" cannot be quantified easily, during my time as CEO and developer of Recital I have seen hundreds if not thousands of companies come and go. Our customers rely on us -- and we are still here for them.
When the time comes just drop a line and you'll get a short list of others - sometimes including arguments or at least the point argued with ;-)
Similarly Lianja and Recital are not really known over here and perception is half of the game - might offer some points on POV in the old world as well.
Just say when...

avianmanagement
2013-03-03, 12:32
Do you not think that importing a whole VFP project into Linaja is a little like saying I have a FoxPro 2.6 app that I want to just import into VFP 9 and run as it is, with screens looking as they did in FoxPro 2.6 ?

As a developer I understand the need to get an old system running in Lianja so that I can offer my clients a future with cloud and IPad and tablet access to system which is where the world is going IMHO.

I see the benefits of Lianja is that I do not need to learn a new language . I looked many years ago at .NET and walked away shaking my head as the learning curve was just too steep for me, and I'm glad now I did.

With Lianja I can use my, limited, knowledge of VFP to make apps that do what my clients want, and they will run on the platforms of the future, tablets, cloud etc.

When I first looked at Lianja I too thought, oh great import whole VFP project and run as is. I also tried to do that. But the more I look at it the more I realize that for me it is more a case of , drop my data and business rules in here, use Linaja pages and set up new 'forms' in the way lianaj is designed to run and off we go.

If all your business rules are outside of your Ui, as IMHO they should be, then the move will not be too great. Ok yes you have to create new 'forms', but the data structure and business locic can be almost reused as is.

Yes it costs to recode, and for small shops that is hard, I'm a one man band, but so is life and if we want to move with the times then we have to bite the bullet and go for it.

I think Barry and the team at Lianja have done a fantastic job so far and if they continue with the way they are listening to developers and add things into Lianja that we need as they have been doing over the past few months I really think that they, and we, are onto a winner. I have yet to come across another development team that listens to their users the way these guys have and added the functionality that we need so fast

If this is what is has been like before the release of the first edition we are paying for, imagine what we will be able to do with it three or four years down the line

Just my 2 cents worth

hmischel@diligentsystems.com
2013-03-03, 16:27
I think many of is would love to have a way to just import our existing fox apps and be off to the races. Realistically though, my existing app layouts would never port as is to a tablet. Every company I have ever worked at has it own unique culture . I never heard of Recital before, but I am extremely impressed with how the Lianja engineers are listening to what we the developers have to say. I like the Lianja/Recital culture. I moved away from VFP a couple years ago and like every other VFP developer started building apps in other languages/technologies. I eventually settled on Sencha EXTJS/Touch/ Javascript/PHP and SQL Server. Simply because Sencha creates visually appealing interfaces that my clients were excited about. However, I spent countless sleepless nights getting apps to work while trying to debug issues across several different products/languages. It was not uncommon for me to be running a SQL Profiler trace, Fiddler, chrome console etc to pinpoint a bug. Coming from VFP I couldn't believe that someone hadn't come up with a data-centric scripting language that could just attach to and use a database and reference that data without jumping through hoops. I see Lianja as that solution and look forward to being able to sell custom desktop, web and mobile apps to my clients.

Herb

lazyfox
2013-03-04, 00:32
I think many of is would love to have a way to just import our existing fox apps and be off to the races. Realistically though, my existing app layouts would never port as is to a tablet.
Realistically getting 100% coverage will be uneconomical, as writing out code for all the edge cases seldom encountered will be too expensive. The strategy to put that into user land makes total sense if others will not only run the importers but look at the issues surfacing with their import material and either create clearly defined test cases or better try to fix the issue and return that fix to the common code base.


Coming from VFP I couldn't believe that someone hadn't come up with a data-centric scripting language that could just attach to and use a database and reference that data without jumping through hoops. I see Lianja as that solution and look forward to being able to sell custom desktop, web and mobile apps to my clients.

As I don't have many customers running programs solely developed by me but but am more often booked to enhance existing packages adoption of Lianja more of a concern with me. There are some attempts in some other packages to stay at a more table-level local representation, but none so rounded as Lianja. Cross system GUI being the second part where something as beautiful as pure python is currently is years behind.

barrymavin
2013-03-04, 03:13
There are some attempts in some other packages to stay at a more table-level local representation, but none so rounded as Lianja. Cross system GUI being the second part where something as beautiful as pure python is currently is years behind.

In fact the Python support is quite seamless. As you know you have all the VFP UI classes + much more available to all of the supported scripting languages; VFP, Python, PHP and JavaScript.

Less of a learning curve.

robertjacobs
2013-03-04, 11:32
Yes - We are serious about moving forward with Lianja and want to offer all we can as far as providing positive and constructive testing. No one is expecting 100% import and run. The forum is titled MIGRATION and this implies moving what you have to something newer and obviously better. To save 80% of coding effort is a step in the right direction.

I think the problem now is there is no roadmap for importing VFP other then running the importer. We have played with it but we do not know what are it's future plans. We are not telling the development team how to prioritize your work - We only want to know what we don't know so we can plan for the future. For example, the importer as it is now is purely code based. Is it possible the importer may generate visual controls since vfp forms and vcx controls can now be embedded in a custom section. If so then is there merit in testing it as it is now or should we wait. This is all I was saying when I originally opened this thread.

lazyfox
2013-03-04, 15:34
In fact the Python support is quite seamless. As you know you have all the VFP UI classes + much more available to all of the supported scripting languages; VFP, Python, PHP and JavaScript.Less of a learning curve.

I should have underlined and embolded "pure" - I am quite happy with the option to play hedgehog and hare when somebody asks about one of the other languages ;-)

lazyfox
2013-03-05, 06:11
I think the problem now is there is no roadmap for importing VFP other then running the importer. We have played with it but we do not know what are it's future plans. We are not telling the development team how to prioritize your work - We only want to know what we don't know so we can plan for the future. For example, the importer as it is now is purely code based. Is it possible the importer may generate visual controls since vfp forms and vcx controls can now be embedded in a custom section. If so then is there merit in testing it as it is now or should we wait.

Robert, speaking only for myself I want the importer to generate a skeleton which can be made runnable within a tiny percentage of the original vfp code development time. There will be some things not implemented or done differently on Lianja, but hacking the few things your app encounters is faster: if I encounter them a second or third time, importer code will be enhanced. If there is a real need to port a lot of complex aggregated controls and/or forms into another format - of course it can be done, it is only code and data. Did that generating Ironpython Winforms code and later XAML from vcx/scx. But that is IMO a customer need: if somebody has 500+ scx he wants to port into another GUI representation, he can do it and if he puts his changes on the wiki others will benefit. If I encounter such a situation as dev paid to port, I will point out the existing tools, will offer to enhance the importer further and will on completion ask if I am allowed to add such changes to the wiki -but that decision is for the customer paying me for developing the enhancement to make.
But trying to get everything thinkable/doable is a certain way never to finish with the product. Look at your code, set yourself a realistic first goal and a target you are willing to spend your own effort on and work with both Lianja and your own code example. If you encounter ***specific*** problems, post here or perhaps open a ticket if you run into a bug.

robertjacobs
2013-03-06, 19:50
Hi Thomas

Are there considerations or possibility for a Code Analyser to report program code lines not supported in Lianja?

lazyfox
2013-03-07, 11:21
Are there considerations or possibility for a Code Analyser to report program code lines not supported in Lianja?

Hi Robert,

you are not the first to think about that ;-) The task breaks for me down into:
1) create a test-driven approach to measure Lianja compatibility in commands, functions and PEM usage (including set/sys)
2) create a distinct report of the commands, functions and PEM usage (including set/sys) used in the specific project
3) change source according to a best practice replacement list if such a beast exists, at least half automatic by providing comments and/or macros

I have an attack vector into 1) planned already and tentatively begun by building a database of vfp commands, functions and PEM, but for the last 4 month was busy with other stuff - Lianja is non-paying for me, even if I expect to monetarize later - so when I am bullied with money for vfp or other stuff Lianja effort currently takes a back seat. Also there are other interesting things in Lianja I have not even begun to scratch... 2) should be possible with little effort, some of that concerning arrays called with () brackets or adapting the source of a vfp-Lint program or a documenting package. 3) would be entirely possible to grow from expiriences of the devs porting.

robertjacobs
2013-03-08, 10:27
Thomas

This has probably already been discussed so maybe you can direct me to the right spot to do some reading. I am wondering why the generated code from VFP - Tools - Class Browser is able to set all properties within the FORM CLASS through ADD OBJECT whereas Lianja importer creates a CLASS definition instead.

lazyfox
2013-03-08, 22:05
This has probably already been discussed so maybe you can direct me to the right spot to do some reading. I am wondering why the generated code from VFP - Tools - Class Browser is able to set all properties within the FORM CLASS through ADD OBJECT whereas Lianja importer creates a CLASS definition instead.

probably historic - the very first version of the Lianja importer used object.Addobject() and wrote out the pseudo-subclasses as classes.
SWAG: was necessary as the number of parameters are limited.
That version had some problems with private/protected, some newly defined properties and array definitions, which are in sepearate memo fields.
At that time Lianja had no support for the "Add object with" - syntax generated by vfp class browser, so running such files was impossible.
So I enhanced the Lianja importer for these structures - still keeping the .addobject() and "realized pseudo classes" and added some small fixes to beautify
(routines to abstract clauses with less than total chars like "endcas"). Then the importer was changed to work on "add object" but with the same basic modus operandi during my timeout and according to Barry there is a newer version around which has more ticket items fixed. This newer version was not included yet in RC4, so I cannot say anything about that.
Running vfp Class Browser output in Lianja will fail at the moment if class definitions are not ordered Grandpa-Pa-kiddies in Lianja, whereas vfp works with "unordered" writeout as well and reorders classes in vcx due to editing. After looking at the vfp class browser code implementing, fixes and changes in there looks like real work, so the idea to write the importers quickly again to the needs of Lianja made sense back then - changing vfp browser code would take longer as it is written quite old style.

Also the vfp syntax for overwritten pseudo-subclassed methods with many dots in the method name is ... counterintuitive at first encounter ;-) Lianja being able to assign new functions as methods might take another approach (resulting in totally different code to reach same behaviour as vfp interpreting vfp-typical code) before adding such syntax for subclasses of deeply containered controls - but that is for Barry to decide. Having a "form-only" real subclass IMO is a cleaner approach, even if in reality only few people looked at the minute details in vfp scx/vcx behaviour - Drew Speedie was one of the best tinkerers in that area.