Something like Objects in OOP?

[glpunzi]

Hi all,

I'm evaluating LiveCode again, to develop an ERP.

I would like to know if there are some methodology near to OOP.

As far as I know, there aren't anything like DataBinding in LiveCode, and we need to use directly SQL statements in events to work with a datagrid.

Because this way of work is a little ugly to me, I'm looking for something like creating "Objects" where I can model the logic and do something like.

Code: Select all

put "Customer.Bills" into datagrid "Customer Bills"

And in Customer.Bills I do the search returning the data for the Datagrid. Later, hen selected, do the Master detail relationship (I don't know but this is not for this post)

Some idea?

[dunbarx]

It seems like you could write a function:

put yourQuery(customer,bills) into dataGrid "CustomerBills"

function yourQuery customer,bills
--do stuff to collect the data you need
return dataYouNeed
end yourQuery

Not sure how this addresses your OOP question, but the routine falls easily and natively into LC's capabilities.

Craig Newman

[glpunzi]

You are talking about a Stack working as library, for example (a Customer stack maybe?), and inside, functions for customers, to do something like.

put customerBills(customerID) into dataGrid "CustomerBills"

I uderstood you correctly?

[dunbarx]

Hmmm.

I was thinking that the function could query a database, do some processing, and return formatted data suitable for direct insertion into your datagrid. If the data set is not too large, you can certainly keep the data inside a stack. I do this with data sets up to 5000 records, and have no issues. Many on this list are adamant about using databases as opposed to internal stack based record holders. They may be right.

In either case, the method I thought of holds. Unless I am not understanding something central to your question.

Craig Newman

[mwieder]

There's unfortunately nothing built-in to handle the Customer.Bills type of OOP - you'll have to write your own library routines for this. I do this sort of disambiguation with things like

set the itemDelimiter to "."

and then parse my way down the string. The lack of user-defined structures is also a pain.

[glpunzi]

There's unfortunately nothing built-in to handle the Customer.Bills type of OOP - you'll have to write your own library routines for this. I do this sort of disambiguation with things like

set the itemDelimiter to "."

and then parse my way down the string. The lack of user-defined structures is also a pain.

Hi, thanks for your answer.

I'm not talking about write Customer.Bills as is. I ask for the best way to reuse code, because an ERP (with POS, store, stocks, sells, shopping, logistics, production and so on..) is a big project, and I need to know, what is the right way, to centralize code in some place, to reuse in all the application.

In a Customer form (card, stack, I don' know what is the right name here), with a "purchase invoices" tab for example, I need to show a datagrid with the customer's purchase invoices for example, but I don't want to build the SQL from there, because I will need the same information to get this data in other place of the application, and If something changes, I need to mdify in more than one script.

For this reason, I ask what is the right way to reuse code in Livecode, and

I was thinking that the function could query a database, do some processing, and return formatted data suitable for direct insertion into your datagrid. If the data set is not too large, you can certainly keep the data inside a stack. I do this with data sets up to 5000 records, and have no issues. Many on this list are adamant about using databases as opposed to internal stack based record holders. They may be right.

Could be very suitable in some projects, but an ERP could manage a lot of data from various years, 5000 product references, or Invoices, Quotes and so on, is not enough, and this app will work in a multiuser enviroment.

Probably, I don't ask correctly what I looking for in my first question.

In my previous message I wrote:

You are talking about a Stack working as library, for example (a Customer stack maybe?), and inside, functions for customers, to do something like.

put customerBills(customerID) into dataGrid "CustomerBills"

I uderstood you correctly?

This is the way to go? Or there are something better to do what I need? There are something like .bas modules containing only code in LiveCode?

[BvG]

There's a plethora of tools to reuse code.

Obviously the first to use is always the inherent message path. This works kind of like a preset, unchangeable inheritance system. For example, if you want to do all buttons in your stack to do the same thing, you can add a "mouseUp" handler to the stacks script, and that will be executed by all buttons that do not have a mouseUp handler themselves.

The next extension of this is librarystack, frontscripts and backscripts (look them up in the dictionary). these allow to modify the message path with your own code, fore example, you can make all buttons in your current application do the same thing by doing "insert the script of button "MasterBlaster" into the front". Note that frontscript can interfere with and disable the IDE's functionality, so watch out

furthermore, you can use behaviors, which is intended to allow a kind of overwriting. With these, you can add button scripts to any object, which then behave as if those scripts are actually in the object you added them to ( expecially considering "me" and "this" and "the target").

You are correct that there is no way to add scripts from plain text files as code. Short stuff can be implemented using "do" (max 10 lines) or "value" (only logical and calculation), but they're not useful for code sharing, it's more about flexibility of execution. Because of that, most commercial add-ons for LC you can buy work as library stacks (they have the added benefit of having a password for secret/commercial code.

the message path goes like this (note that many built in messages go directly to the card):

frontscripts (if exist) -> object -> behaviors -> group(s) (if exist) -> card -> stack -> mainstack (if not the same as stack) -> stacks in use (if exist) -> backsripts (if exist) -> engine

for completeness sake (not really about code sharing, but important to code execution): To issue custom or built in messages using code, you'd use "send", "call", or "dispatch".

[glpunzi]

There's a plethora of tools to reuse code.

Obviously the first to use is always the inherent message path. This works kind of like a preset, unchangeable inheritance system. For example, if you want to do all buttons in your stack to do the same thing, you can add a "mouseUp" handler to the stacks script, and that will be executed by all buttons that do not have a mouseUp handler themselves.

The next extension of this is librarystack, frontscripts and backscripts (look them up in the dictionary). these allow to modify the message path with your own code, fore example, you can make all buttons in your current application do the same thing by doing "insert the script of button "MasterBlaster" into the front". Note that frontscript can interfere with and disable the IDE's functionality, so watch out

furthermore, you can use behaviors, which is intended to allow a kind of overwriting. With these, you can add button scripts to any object, which then behave as if those scripts are actually in the object you added them to ( expecially considering "me" and "this" and "the target").

You are correct that there is no way to add scripts from plain text files as code. Short stuff can be implemented using "do" (max 10 lines) or "value" (only logical and calculation), but they're not useful for code sharing, it's more about flexibility of execution. Because of that, most commercial add-ons for LC you can buy work as library stacks (they have the added benefit of having a password for secret/commercial code.

the message path goes like this (note that many built in messages go directly to the card):

frontscripts (if exist) -> object -> behaviors -> group(s) (if exist) -> card -> stack -> mainstack (if not the same as stack) -> stacks in use (if exist) -> backsripts (if exist) -> engine

for completeness sake (not really about code sharing, but important to code execution): To issue custom or built in messages using code, you'd use "send", "call", or "dispatch".

Tanks for your time BvG.

I will study use Stacks (one for Customers, Stocks and so on...) and inside this stacks functions to return the data needed.

To clarify, I'm talking about reusing code, inside the same application/project.

Regards.

[mwieder]

Check out Richard Gaskin's writeup on the xtalk message path:

http://www.fourthworld.com/embassy/arti ... _path.html

I think code reusability is one of LiveCode's best features. But there's nothing that forces you to do this or presents obstacles. You have to work out a strategy or strategies for yourself. Using library stacks is useful for some scenarios. Placement of code in the stack/card/control scripts is useful for other situations. You're heading in the right direction in thinking about separating your sql logic from the presentation layer.

[glpunzi]

Check out Richard Gaskin's writeup on the xtalk message path:

http://www.fourthworld.com/embassy/arti ... _path.html

I think code reusability is one of LiveCode's best features. But there's nothing that forces you to do this or presents obstacles. You have to work out a strategy or strategies for yourself. Using library stacks is useful for some scenarios. Placement of code in the stack/card/control scripts is useful for other situations. You're heading in the right direction in thinking about separating your sql logic from the presentation layer.

Interesting, then, if I don't misunderstood, I can have a generic stack for Customers functions, and, for exmaple, in a stack where I can show a customer, on his message "openStack" write

start using stack "Customer"

and on closeStack

stop using stack "Customer"

And inside this stack, I will can call to Customer stack functions, True?

But then, another question. What is the best way to organize stacks and files to share development over the same project?

I mean..In my project, an ERP, will have a section of stocks, another for billing, another for logistics and so on....
Every module is "independent" but will be accesible (if the customer paied for it) for the same app thath works as a main container.

For example, imagine thath I have 5 .livecode files (I don't know if it's the right way, I'm trying to understand how to modularize my development to reuse)
Logistics.livecode (the logic), LogisticsUI.livecode (all referent to UI of logistics) Sales.livecode (the logic) and SalesUI.livecode (all referent to UI of sales) and Main.livecode (The main form of the application with splash screen and so on, and from here, I call to open the form for logistics, for Sales and so on...)

How can I call this "externals" .livecode files, and most important, "join" this in one only executable to deploy?.

Is this the way to go? I suppose some modularitazion like this is needed, mainly if there are more than one developer in the same project..while one is working in Sales module, other is working on Logistics.

I don't know if I explained correctly.

[townsend]

Make things easy for yourself. Even though you have 5 modules, which individual customers may or may not have paid for, put all your handler routines in one stack. Just because a module does not use a handler, does not mean it's inefficient to have it in the library.

The key point is to put any routine that would be used more than once in a library handler. That way, if you need to make a change to the code, it only happens in one place. I noticed that putting all my handlers in a separate library file, takes a few more clicks during development, so I put them in the main stack area. When the project is done, I'll just cut them out of the main stack and paste them into the library.

[glpunzi]

Make things easy for yourself. Even though you have 5 modules, which individual customers may or may not have paid for, put all your handler routines in one stack. Just because a module does not use a handler, does not mean it's inefficient to have it in the library.

The key point is to put any routine that would be used more than once in a library handler. That way, if you need to make a change to the code, it only happens in one place. I noticed that putting all my handlers in a separate library file, takes a few more clicks during development, so I put them in the main stack area. When the project is done, I'll just cut them out of the main stack and paste them into the library.

But this limits if more than one developer are involved.

Regards.

[townsend]

When more than one developer is involved, you need a check-in, check-out, process. Even though liveCode does not have this built in, you can easily replicate this via email for your team.

1- Everybody is using the same library file.
2- You need to make a change to one of the handlers.
3- You send a email telling the other team members not to modify that handler because it is being updated.
4- You update the handler on your machine only.
5- When the modifications are made, you copy and past the handler into an email and tell the other team members to replace the old handler with the new version.

I'm sure you see the logic here. Practically speaking, I would go one step further and designate the team leader as the librarian, who coordinates this check-in and check-out process. Their responsibility would be to keep the master copy of the library and send the entire library out to the entire team whenever there is an addition or update. Otherwise mistakes can easily happen.

[townsend]

Another even better scenario with the case of multiple developers, is to assign owners to each handler. In this way each developer is responsible for their set of handlers and sends out their library to the other developers when additions and updates are made. In this case, multiple libraries work better.

[glpunzi]

I will try to apply all your advices.

Thanks a lot.