Radicore Forum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » RADICORE » How To » Radicore tutorial point (Radicore for PHP - Tutorial (Part 3) - need help)
Radicore tutorial point [message #7216] Sun, 02 September 2018 03:12 Go to next message
Ellie is currently offline  Ellie
Messages: 9
Registered: August 2018
Junior Member
Where there are lines:
to force the TREE_LEVEL_SEQ field to be non-editable all all screens except the search screen, which can be done by copying across the empty _cm_changeConfig() method from file std.table.class.inc, then filling it with the code shown below:

The Question is: Are those changes to be made in test/screens/<language> screen files respectively?

Pardon my dummy question ))

Re: Radicore tutorial point [message #7217 is a reply to message #7216] Sun, 02 September 2018 04:45 Go to previous messageGo to next message
AJM is currently offline  AJM
Messages: 2367
Registered: April 2006
Location: Surrey, UK
Senior Member
No. The change is made to your <table>.class.inc file. By default this does not exist in any table class, so it inherits the empty method from the abstract table class (std.table.class.inc). You copy this empty method into your table class then put some code into it so that when this method is called it executes this override method instead of the default method.

Re: Radicore tutorial point [message #7218 is a reply to message #7217] Sun, 02 September 2018 09:30 Go to previous messageGo to next message
Ellie is currently offline  Ellie
Messages: 9
Registered: August 2018
Junior Member
Thanx a lot!
I think there should be little updates made to tutorial instructions - where it says about table/DB relationships, cos in current versions they're divided into child & parent relationships (though to me it is no big deal) to be more precise.

Thanks for nice framework, i wonder why it is not popular.
Re: Radicore tutorial point [message #7220 is a reply to message #7218] Mon, 03 September 2018 04:21 Go to previous message
AJM is currently offline  AJM
Messages: 2367
Registered: April 2006
Location: Surrey, UK
Senior Member
When the documentation refers to "relationships" it means both parent relationships and child relationships. A relationship always requires two tables - the "one" (parent) and the "many" (child), therefore you can have relationships where the current table is the parent *AND* where the current table is the child. Don't forget that a table can have more than one parent as well as more than one child.

Previous Topic: need help
Next Topic: $lock_str FOR UPDATE FOR $tablename with PostgreSQL
Goto Forum:
  


Current Time: Fri Nov 22 00:41:10 EST 2024

Total time taken to generate the page: 0.03027 seconds