Hi list,

I'm looking into converting a half-finished small timekeeping/billing application of mine from .Net to Lazarus/Freepascal. It runs on SQL Server 2008.

I'm thinking about trying to separate out the database layer (using something like tiOPF perhaps) from the presentation layer.

I could then write a Lazarus GUI to deal with the data. (Not even mentioning web interfaces for now, too much to learn ;)

While I'm doing that, I thought about using character mode terminals (DOS or Linux shell) for quick data entry. I've once looked at FreeVision (about 10 years ago), but was even more of a Pascal/programming newbie than now, so couldn't get it to work.

Is it worth looking into FreeVision or could I better forget about it? If so, I suppose the old FreePascal IDE would be a good example to study?

Regards,
Reinier

It should definitely work.

Whether it's recommended is another matter. I don't think so. You'd be better of with a web interface then.

Michael.

Reinier Olislagers wrote

I'm thinking about trying to separate out the database layer (using something like tiOPF perhaps) from the presentation layer.

Good choice! :-)

While I'm doing that, I thought about using character mode terminals (DOS or Linux shell) for quick data entry.

As Michael said, it could definitely work. But is there any specific reason why you would like to choose a terminal app over a GUI (desktop) app? Or even a Web app? Easy deployment with little dependencies, end-users are already used to terminal apps etc?

If you do use tiOPF, you could always use tiOPF's MGM (Model-GUI-Mediator) which makes GUI binding very easy with very little code. MGM already supports fpGUI, LCL and VCL. I would obviously recommend fpGUI for the job, which gives you lots of possibilities to customize the look of your app, and it has very low library dependencies... but them I might be a bit bias towards fpGUI.

Lazarus is very easy to learn, you can read the wiki and now there is also a book in english explaining how to use it.

Felipe Monteiro de Carvalho wrote

Lazarus is very easy to learn, you can read the wiki and now there is also a book in english explaining how to use it.

Thanks Felipe & Michael!

Yes, I'm already doing stuff in Lazarus (even got the book). I'd be looking at the FreeVision app in addition to a Lazarus app, using the same FreePascal business layer units.

But, as Michael said, I could just as well look into creating a web server module (FastCGI or whatever) using those business layer units first... This would have the advantage that people using mobile devices could use it.

Anyway, first going to get back to improvements for my FCL-DB export unit for XML...

Thanks,
Reinier

Goeiemore Graeme (& almal),

I think I didn't make myself clear. My intentions were to:
1. Create a business layer using FreePascal
2. Create a Lazarus desktop (maybe smartphone) app that uses the units in 1.
3. To see if I could create a really fast user entry solution, create a FreeVision app using the units in 1.
4. Create a web application (using e.g. FastCGI) using the units in 1.

With 1 and 2 being "compulsory" or at least first steps, the rest can come later.

Biased? I wouldn't think so ;)

I'll certainly keep it under consideration - and if I use tiOPF, I'd surely use MGM for Lazarus code.

Keeping the application modular will give me the chance to learn new things (web apps, fpGUI) without messing too much with things I know a bit about (FreePascal, database access, Lazarus desktop apps).

Thanks,
Reinier

Reinier Olislagers wrote

I think I didn't make myself clear. My intentions were to: 1. Create a business layer using FreePascal 2. Create a Lazarus desktop (maybe smartphone) app that uses the units in 1.

My apologies; from your original message I didn't know step 2 was compulsory. I thought in step 2 you are considering FreeVision or some GUI desktop app.

3. To see if I could create a really fast user entry solution, create a FreeVision app using the units in 1.

Just curious as to why you think a terminal app (FreeVision) would be faster for data input than a well designed GUI desktop app? I have built many desktop GUI apps thats sole purpose is to input data. For such apps I streamlined the interface so there are no popup dialogs that require a mouse, keyboard navigation being a must, enter key also inserts data and moves to the next data field, focused widget optimization etc. If they get distracted by the desktop, a simple F11 keypress makes the app fullscreen.

I'm not saying a terminal app is the wrong way to go (I have many terminal apps I still use on a daily basis, even in my Gnome desktop), I just wanted to know your thoughts on the subject.

Graeme Geldenhuys wrote

On 4 August 2011 11:14, Reinier Olislagers wrote: My apologies; from your original message I didn't know step 2 was compulsory. I thought in step 2 you are considering FreeVision or some GUI desktop app.

No problem ;)

Just curious as to why you think a terminal app (FreeVision) would be faster for data input than a well designed GUI desktop app?

<...>

I'm not saying a terminal app is the wrong way to go (I have many terminal apps I still use on a daily basis, even in my Gnome desktop), I just wanted to know your thoughts on the subject.

Actually, it's just going to be an experiment to compare the two and see which one is faster. (And also personal taste, I must admit - I'm still drawn to using a mouse when entering data on Windows apps, even though I know I can use the tab/cursor keys etc.)

When I've actually coded something, I might get back to you guys ;)

Also, it obviously is a good test of the modularity of the code, but I could perform the same test with a web interface.

Thanks,
Reinier

Reinier Olislagers wrote

which one is faster. (And also personal taste, I must admit - I'm still drawn to using a mouse when entering data on Windows apps, even though I know I can use the tab/cursor keys etc.)

I fully understand that, most GUI desktop apps are not well designed for keyboard navigation. Yes they tend to work, but nobody wants to tab 10 times just to get to the right text entry field. This is why I mentioned "purpose built for data input". I had to tweak our data input apps to be much more "keyboard efficient": automatically move to the next field, default focus is more precise etc. It only takes a little bit of effort from the developers side, but makes a huge difference for the data capturer.

Also, it obviously is a good test of the modularity of the code, but I could perform the same test with a web interface.

Try writing Unit Tests instead. When creating unit tests, you very quickly find mistakes in your object design. Plus you have something that actually validates your code too. :-)

One step better, would be to implement Test Drive Development. Write the unit tests first, using the API you WISH YOU HAD, then implement that API. Your already existing unit tests will verify when you get it right. This actually makes your object API's a lot more developer friendly.