Hello,
i am very new to Oxid, i just found views and cntrollers, no models.
can somebody say me if there are models?
_best,
T
Hi,
our MVC is based on this structure:
Model => /core
View => /out
Controller => /views
Regards Stefan
is there any documentation about your ORM Mapper?
i looked for a abstract database layer and found querys in the models.
is there no abstract database layer?
$ox_mod_… = oxNew( “ox_mod_…” );
$ox_mod_…->init( “tablename” );
$ox_mod_…->load(1);
var_dump($ox_mod_…->tablename__status);
$ox_mod_…->tablename__status->rawValue = ‘foo’;
$ox_mod_…->save();
i can’t sind a function witch allows me to create a new row, can somebody say me how to do that?
if i use the save function without an id the default id’s are very strange 716, 7166, 71691, 716616, 4294967295
T,
this is also an issue for me as I intend to introduce completely new data structures for additional functionality as well.
I have been promised to get some more dev documentation. Doxygen docu does not seem sufficient to me. Some more software design documents and state diagrams for the major business processes could really help out.
Did you get any hints and/or more details? I am still not sure if Oxid is inteded to be extended in this way. Dispite the possibility of reverse engineering and hacking the existing code I would love to extend the friendly way 
Regards,
Pascal
Okay, adding columns is easy: Just do it inside the database and values will be available automagically in the appropriate model.
I also succeeded in adding new models. It boils down to deriving from oxBase or oxI18n and creating the corresponding database table. Just watch out for naming conventions. If you intend to have an oxFoo model you should not name your oxAdminViews like just Foo but Foos hence the API will not be able to distinguish between oxFoo and Foo in terms of name resolution in the factory.
I’m happy 
Regards
[QUOTE=PCO;25198]Okay, adding columns is easy: Just do it inside the database and values will be available automagically in the appropriate model.
I also succeeded in adding new models. It boils down to deriving from oxBase or oxI18n and creating the corresponding database table. Just watch out for naming conventions. If you intend to have an oxFoo model you should not name your oxAdminViews like just Foo but Foos hence the API will not be able to distinguish between oxFoo and Foo in terms of name resolution in the factory.
I’m happy
Regards[/QUOTE]
Could you explain that a little more detailed, pls.?
[QUOTE=avenger;25228]Could you explain that a little more detailed, pls.?[/QUOTE]
It is not too difficult, when you are following this helpful howto: http://www.oxid-esales.com/en/news/blog/how-extend-oxid-eshop-part2
What you have to do is to extend oxBase or oxI18n, whether you need i18n or not. Have a look at oxDiscount as a start.
After having created your module and placed it in the modules directory (e.g. think of a module “oxMyOwn”) you have to add it to the modules list in the administration section of eshop:
oxBase => myownmodules/oxmyown
My current problem is, that this works fine for ONE additional model but it will completely fail when you are going to add additional models. This does not work:
oxBase => myownmodules/oxmyown&myownmodules/oxmyotherown
This is a huge deal. So basically, if you intend to add multiple modules that shall coexists I am not sure of the module-functionality is the correct choice for accomplishing this.
I am wondering if such a functionality is intended by Oxid AG.
oxBase => myownmodules/oxmyown
oxBase => myownmodules/oxmyotherown
Regards
[QUOTE=PCO;25236]
oxBase => myownmodules/oxmyown
oxBase => myownmodules/oxmyotherown
[/QUOTE]
use:
oxBase => myownmodules/oxmyown&oxmyotherown
cheers,
achim
This is a huge deal. So basically, if you intend to add multiple modules that shall coexists I am not sure of the module-functionality is the correct choice for accomplishing this.
Yup, modules can conflict, therfore you have to call the parent::methodName() method in every method you intend to overwrite.
the oxid module system is, unlike magentos module system, very very simple. But you’re right, in the worst case, modules could conflict with each other.
but:
oxBase => myownmodules/oxmyown&myownmodules/oxmyotherown
This works defininetly. both modules have to look like this
class oxmyown extends oxmyown_parent {
}
and
class oxmyotherown extends oxmyotherown_parent {
}
you have to extend your module classes ALWAYS with a class named like your class and the suffix “_parent”. This _parent class is created automatically by the shop.
[QUOTE=csimon;25295]Yup, modules can conflict…[/QUOTE]
Why that?
What could be the problem?
So far I have not experienced any.
csimon,
if you take a look at this one:
You can see that concatenating with ampersand is not the solution I was looking for. Of course I added _parent but anyway you will get an etxension chain instead of parallel models. This might work if you have, say, two types of baskets that do not interfere and use the same db table, but if you tend to create multiple core models from oxBase which do have nothing in common you will fail miserably with the default Oxid module attempt.
You will have to create and register your models manually which means, again, edit the distribution source. Trust me, I tried id, it won’t work for new core models the “oxid module way”.
Regards,
Pascal
You can write core classes and without using the module system. You have to place them simply in the “core” or “views” folder, oxid uses an autoloader, so that “oxNew(‘myClass’)” will work without any registration, if the class file is placed in the core or views folder.
example:
class myClass extends oxBase {
}
That works seamlessly, without editing the distribution source. if you want to alter the basic behavior of oxid, you have to use the module system. But if you simply want to add additional functionality which don’t alters any shop behavior, you can use my attempt as explained.
That’s exactly what I have done with approx 15 new entities. Anyway this means you have to include these new classes somewhere which is not intended by default. You have two chances: Add models to core/ folders (which is modification of the core distribution, literally) or add models to modules/myplugin/core/ and the include models via modules/functions.php. Anyway, this has a caveat as modules/functions.php is included way too early in index.php and oxajax.php. If you’s like to extend oxBase you have to make sure that these entities are known before you declare your own models. So, again, you have to slightly modify the core distribution.
Anyway, that seems to be the way to go.