Hi

Im trying xoops 2.5.7.1 and common utilities in localhost...i have followed the intruction in rm readme..but i received the error below...


Common Utilities 2.2.7.5
XOOPS 2.5.7.1

Apache 2.2.26
PHP 5.3.27
Mysql 5.5.34


-----------------------------------

( ! ) Parse error: syntax error, unexpected T_USE, expecting T_FUNCTION in C:\Program Files\VertrigoServ\www\test\modules\rmcommon\class\helpers\httprequest.class.php on line 14
Call Stack
# Time Memory Function Location
1 0.0020 415632 {main}( ) ..\admin.php:0
2 0.0030 436952 include( 'C:\Program Files\VertrigoServ\www\test\modules\system\header.php' ) ..\admin.php:34
3 0.0040 459104 include_once( 'C:\Program Files\VertrigoServ\www\test\include\cp_header.php' ) ..\header.php:18
4 0.0050 482600 include_once( 'C:\Program Files\VertrigoServ\www\test\mainfile.php' ) ..\cp_header.php:24
5 0.0090 605488 include( 'C:\Program Files\VertrigoServ\www\test\include\common.php' ) ..\mainfile.php:75
6 0.2380 5768376 XoopsPreload->triggerEvent( ) ..\common.php:359
7 0.2380 5768808 call_user_func ( ) ..\preload.php:140
8 0.2380 5768984 RmcommonCorePreload::eventCoreIncludeCommonEnd( ) ..\preload.php:140
9 0.2380 5769616 RMEvents->run_event( ) ..\core.php:139
10 0.2390 5771616 call_user_func_array ( ) ..\events.php:122
11 0.2390 5771632 Twop6RmcommonPreload::eventRmcommonXoopsCommonEnd( ) ..\events.php:122
12 0.2390 5771848 rmc_autoloader( ) ..\events.php:0

Please ALWAYS include your XOOPS version, PHP version, your module's version, and the steps to reproduce the problem!!!

Please also turn on in Admin the Debug, and let us know what errors, if any, it shows.

Hello ..
I've got a problem
eXtGallery not to display images on the site
Block shows the name of the image but I did not show the picture after lifting
Please help ...

Quote:
It might not be in the first release, but the plan is definitely to have it. Richard has already experimented with a MVC design based on Mojavi framework, which was also the starting point of Symfony. This MVC-design done by Richard was kind of a "proof of concept" and was on top of XMF from Trabis.

But MVC is not standing still, and there is recently an interesting development toward "Action-Domain-Response" model by Paul Jones. You can read more about it here:
http://paul-m-jones.com/archives/5970

Richard has also looked into it and did some experiments with this concept, and he liked that approach.

I think that with the current work by Richard and with the MVC done by Eduardo in RMC, they should be able to merge the best ideas into a nice MVC design in future XOOPS version.

As you see, there is a lot of cool things happening in XOOPS, and once certain decisions related to architecture of the future XOOPS are made and implemented, things will move much faster.

Hi friends, i'm looking for a way to return an xforum installation to the old newbb or CBB

perhaps a conversor to migrate from xforum to vanilla forums?
i have many sites with xoops but a customer needs the migration, thanks in advance

is MVC part of xoops 2.6?

What is MVC?

M - Model = This is the portion that DOES the work.

C - Controller = This is the portion that Controls what happens.

V - View = This is the actual user interface that the user accesses and views.

With Xoops we have a system that for years basically has consisted of a template that is loaded with values from a module. In other words we are already 2/3rds the way there with a standard module.

In my "advanced" java class our instructor explained this model in a manner where each component of an MVC design should theoretically setup in a manner that it can be pulled out of the program and replaced without impacting the program.

What this means for instance is the Model did all of the actual work. It communicates to the database, validates the data, or whatever other job the module is supposed to do. Such as calculate a date or whatever. When writing a Model it is a good idea to have it be able to stand on its own. It should NOT depend on anything being returned to it from the controller or from the view. It should only act on the data sent to it and return any results back to the calling procedure.

The view should also be able to work on its own. It should present data to the user or retrieve data from the user. In my Java class we had to have a console based View and a GUI based view. This entitled that the View wasn't directly dependent on any other component. It only showed what it was told to show and only returned what was requested.

The controller is the brain of the system. It will take input from the view, send it to the model to process and display results back to the view. In my Java class we had to build 2 different controllers to do totally different things with our Model and our View. This allowed us to have two totally different, but similar, programs by just changing the controller but using the original view and original model.

Separating your program into these three components helps in many ways. You can reuse your code easily in other modules and you could actually build a Model that could be used by many different programs or modules like a framework of a sort. You could also make it easier to be compatible with other versions of xoops by insuring all of your xoops related code is in the model. A service provider could be written much easier for xoops 2.6 as well.

Another thing it helps with is testing. phpUnit can test functions much easier in an MVC environment. It can really test the Model objects well since they are designed to be self contained. The controller can also be tested easier because you should be able to run controller functions without a view. The view may not need to be unit tested and may not be able to be unit tested.

Regardless to what some developers might believe MVC is here to stay. It makes sense and in the long run will make a developers life much easier by simplifying the code.

Rodney

Alot of those module where mainly written in 2.4 of XOOPS and the structure of XOOPS 2.5 has changed between 2.5.1 and 2.5.7 -- if you use the discussion on or raise tickets on the http://sourceforge.net/projects/chronolabs the bugs if and when they exist will get fixed...

It is part of the communities responsibility to report this sort of thing, I do not being the only programmer in chronolabs currently have time to review them or and need peer-review from my clients you people at XOOPS...

I have some comments. I have not had time to look at this as I am finishing up my semester. But yes I think there are five considerations at this time that should be considered on building this.

1. XMF, XMF SHOULD be the basis of any module that can make use of it. This will help make a module 2.6 ready and make any necessary conversions MUCH easier.

2. MVC should be the rule for modules of the future. It does make things much easier to debug and sort of forces use of OOP.

3. We need to make a standardized folder format. In the near future we will be looking at automating installations and it is important to try making the zip folders the same so an installation program knows where to put them.
I suggest the following folders which follow the main xoops installation.
html - should contain all files in the proper folders for installation. An
installation program will just take the folder and copy it into the main
directory.
extras - should contain anything extra that isn't normally included in the main
install but may benefit some users.
docs- any help files that may be included. These should be separate and not
installed automatically and should contain any extended help. A future
installer may use this directory to allow someone to install help menus
for a module but for security or to save space may decide not to install.
upgrade - should contain any files or other items needed to upgrade a module
from older versions or perhaps have conversion scripts to allow a new
module to replace an older module.
An install program will likely only use the html and docs folders. The other folders are to help users get their module up and running. May be able to just use the extras folder and not need an upgrade folder.

4. With xoops 2.6 we have a service manager that will allow a module to provide services to other modules. This will become more common place as the manager evolves but in essence a program like xoopspoll that can be used by other programs should have functions setup that are generic and can be accessed on their own by other modules. When building an MVC setup this becomes much easier to do because you can pretty much make the whole "Model" portion into a service manager provider and the "Controller" would make use of it. For xoops 2.5.x you could still make use of such a format but just be aware of the importance to generalize it.

5. Another consideration with an MVC build is that the Model can be built to have objects that are generic and can make service manager service providers easier but can also help clone modules much easier. You should only have to clone the Controller and View portions of the module in this manner. You can leave the original module in place and just copy the view and controller to make a second copy that is totally different than the original. If built with this in mind it can make life much easier in the future.

My semester ends shortly and depending on how next semester lines up and how much I get done during winter break I may be able to help with this. I don't have any pressing projects for xoops other than some service manager stuff I need to finish up for 2.6. I also will only have 2 classes next semester instead of my current 4 which should help dramatically.

Anyhow great start!

Rodney

This will occur if there is no "main" image for the published item.