Can't get to first base - don't have a clue

Login or register to post comments
14 replies [Last post]
Offline
Joined: 05/31/2009

First, let me mention that I am using the jcubed Joomla component - which doesn't seem to be the problem. Let me also mention that I am an experienced developer. I've used numerous frameworks, repositories, case tools, and code generators -- but I have not used QCodo or QCubed.

When I installed, I get the following page which the documentations says I should get. I replaced server specific info with the word "removed". This looks OK so far. When I examine the contents of this page, the settings all seem correct to me.

BUT: Is this display telling me HOW QCubed is currently resolving, or is it providing a list of items I need to define in the QCubed configuration file? Do I need to edit configuration.inc.php or is this telling me that everything is already resolving correctly? It appears from the documentation, that I'm supposed to update the configuration.inc.php file. So, I did that.

BUT, the layout of the directories in the Joomla "com_jqcubed" directory doesn't match the documentation for non-joomla installation of QCubed, so...

Qcodo Development Framework 1.0.0 RC2 (QCubed 1.0 RC2)

Start Page

It worked!

If you are seeing this, then it means that the framework has been successfully installed.

Make sure your database connection properties are up to date, and then you can add tables to your database, and go to either of the following webpages:

* Generate Code - to code generate your tables
* Form Drafts - to view the generated Form Drafts of your database
* Panel Drafts - to run the Qcodo Examples Site locally

For more infromation, please go to the Qcodo website at: http://www.qcodo.com/

QCubed Settings

* QCODO_VERSION = "1.0.0 RC2 (QCubed 1.0 RC2)"
* __SUBDIRECTORY__ = ""
* __VIRTUAL_DIRECTORY__ = "/components/com_jqcubed"
* __INCLUDES__ = "/removed/components/com_jqcubed/qcodo/includes"
* __QCODO_CORE__ = "/removed/components/com_jqcubed/qcodo/includes/qcodo/_core"
* ERROR_PAGE_PATH = "/assets/php/_core/error_page.php"
* PHP Include Path = ".:/removed/components/com_jqcubed/qcodo/includes/:/removed/components/com_jqcubed/classes"
* QApplication::$DocumentRoot = "/removed/components/com_jqcubed"
* QApplication::$EncodingType = "UTF-8"
* QApplication::$PathInfo = ""
* QApplication::$QueryString = "option=com_jqcubed&task=info"
* QApplication::$RequestUri = "/administrator/index.php?option=com_jqcubed&task=info"
* QApplication::$ScriptFilename = "/removed/administrator/index.php"
* QApplication::$ScriptName = "/administrator/index.php"
* QApplication::$ServerAddress = "removed"
* QApplication::$Database[1] = array ( 'adapter' => 'MySqli5', 'server' => 'removed', 'port' => 3306, 'database' => 'removed', 'username' => 'removed', 'password' => 'removed', 'profiling' => false, )

To Be Clear: The correct information for the Joomla Database was listed in QApplication::$Database[1] before I substituted the word "removed". In fact, all of the information was correct, except for the "$PathInfo" field which was empty - and is also empty in the example listed in the QCubed documentation.

HOWEVER:

I don't know what tables I am supposed to add. I assume they would be for an application I want to generate????

I added the tables for the hobby example: http://trac.qcu.be/projects/qcubed/wiki/CodeGeneration

The database parameters are correctly listed in the Start Page - QApplication::$Database[1]

BUT:

1. When I try to generate, it takes a while and then I get a blank screen. I assumed this is because QCubed is trying to generate an application out of the entire Joomla Database. The generation function doesn't ask for table prefix name or anything that would identify the tables to be used.

WHAT DO I DO: Do I used a specific table prefix in the Joomla database? Do I setup a separate database for QCubed? If it's a separate database, then how does Joomla communicate with QCubed?

Since I saw no place to specify a table prefix, I created a separate database for QCubed applications and created the hobby tables. I still get a white screen after a few moments when I click the link to generate code.

2. Here's what I have on the "Panel Drafts" page:

not_found.inc.php
Form Drafts
Panel Drafts
AJAX Dashboard

Select a Class to View/Edit

NOW:

On the "Panel Drafts" page, "not_found.inc.php" looks like an error to me, so I found it in the code. Is this because no applications have been generated - so the directories don't have anything relevant in them, or is this because the QJOOMLA constants haven't been set?

I defined the constants in configuration.inc.php -- at least the one's I could figure out (remember that the layout of the folders in the non-Joomla documentation doesn't match the folder layout in Joomla.

function getFilePath($myfile) {

$formDrafts = __QJOOMLA_DOCROOT__ . __FORM_DRAFTS__;
$formDrafts_gen = __QJOOMLA_DOCROOT__ . __FORM_DRAFTS__ ;
$panelDrafts = __QJOOMLA_DOCROOT__ . __PANEL_DRAFTS__;
$panelDrafts_gen = __QJOOMLA_DOCROOT__ . __PANEL_DRAFTS__ ;
$customForms = __QJOOMLA_PAGES__;
$customTpl = __QJOOMLA_TEMPLATES__;
$customClasses = __QJOOMLA_CLASSES__;
    $languages = __QJOOMLA_DOCROOT__ . '/Languages';

// Construct the file path
$pageStr = DIRECTORY_SEPARATOR . $myfile;

if(!stristr($pageStr,'.php')) {
$pageStr .= ".php";
}

if(stristr($pageStr,'.class.php')){
if(file_exists($customClasses . $pageStr)){
$page = $customClasses . $pageStr;
}
}
elseif(stristr($pageStr,'.tpl.php')){

if(file_exists($customTpl . $pageStr)){
// We've got a hit!
$page = $customTpl . $pageStr;
}
elseif(file_exists($formDrafts_gen . $pageStr)) {
// We've got a hit!
$page = $formDrafts_gen . $pageStr;
}
elseif(file_exists($panelDrafts_gen . $pageStr)) {
// We've got a hit!
$page = $panelDrafts_gen . $pageStr;
}
else {
$page = 'not_found.inc.php';
}
}
else {
if(file_exists($customForms . $pageStr)) {
// We've got a hit!
$page = $customForms . $pageStr;
}
elseif(file_exists($formDrafts . $pageStr)) {
// We've got a hit!
$page = $formDrafts . $pageStr;
}
elseif(file_exists($panelDrafts . $pageStr)) {
// We've got a hit!
$page = $panelDrafts . $pageStr;
}
        elseif(file_exists($languages . $pageStr)) {
            // We've got a hit!
            $page = $languages . $pageStr;
        }
else {
$page = 'not_found.inc.php';
}
}
return $page;
}

So, it appears to me that the information on the start page implies that QCubed is setup correctly and knows where everything is, but the "not_found.inc.php" message on the "Panel Drafts" page - at least according to the getFilePath function - indicates that it cannot find some or all of the paths and is therefore displaying the "not_found.inc.php".

I tried setting up a separate database for QCubed applications. Didn't help.

Apparently, I am connecting to the database since changing the database password to the wrong password and then clicking code generation gives me the white screen immediately. When database password is correct, it takes a while for the white screen to appear.

In any event, here's my situation:

I don't have any more time to figure this out and do trial and error tests until I get something working. I was hoping to use QCubed as the basis for a Joomla application that would be used by many of our customers. We have 5 new customers needing the application which we were going to build using QCubed. I'm sure we could get this working -- eventually, but even if we go back to hand-coding, at least we know how long it will take to complete the application. We simply can't invest our time in the hope that we might get this going when we have no guarantee that we can get it working to meet the promised completion dates for our customers.

So, we will have to use something else -- most likely hand coding from our script library.

I'm still interested in QCubed, and once we have built this application and have met this particular vertical market's requirements, we'll likely look at QCubed again as we develop an application for another vertical market. -- This will take 6 to 12 months before we come back to take another look.

Even so, I'd like to have my questions answered for my own curiosity. Perhaps, we'll find some other uses for QCubed on individual websites sooner than 6 to 12 months.

At this point, I'm mostly interested in determining where I went wrong and what I failed to do. Has anyone successfully installed JCubed and used QCubed / QCodo with Joomla? I'm curious because I am not lazy or stupid and I have wasted many hours playing with it. I doubt that others have gone to the extent of reading the code, reverse-engineering, and troubleshooting required to get this working.

This is frustrating because I am now sitting here asking myself: 1. Is the person who this together a sadist who intentionally didn't provide the required information? 2. Why would anyone, unless they are a sadist, provide a Joomla component and then provide none of the information required to make it work, such as where the files created by the code generator are supposed to go?

It seems like the developer of JCubed could take five minutes to provide basic information that would allow those wanting to make use of his work to successfully install and use JCubed without wasting many hours going through code and guessing at the proper setup.

Steven Warren's picture
Online
Joined: 11/06/2008

I helped Sebastian port the Jqcubed Joomla plugin to The current Qcubed framework. I have it successfully working on two different intranet applications.

To answer a few of your questions:

"When I try to generate, it takes a while and then I get a blank screen. I assumed this is because QCubed is trying to generate an application out of the entire Joomla Database. The generation function doesn't ask for table prefix name or anything that would identify the tables to be used."

This is handled in the codegen_settings.xml file just as it is in Qcubed. I recommend excluding the JOS_ and BAK_ tables in Joomla. I then include the JOS_Users table so I can manipulate it with Qcubed. You should also make sure you can write to the drafts folder.

"1. Is the person who this together a sadist who intentionally didn't provide the required information? 2. Why would anyone, unless they are a sadist, provide a Joomla component and then provide none of the information required to make it work, such as where the files created by the code generator are supposed to go?"

If you look at the Manual install instructions it will explain what modifications were made to Qcubed and in most cases why they were necessary to get Jqcubed to work.
Please note these notes have yet to be updated for the Qcubed changes as we were waiting for Qcubed stable to be released and have not had the time since.

Once you get your form_drafts generated all you need to do is drop them into the pages directory. Then use the plugin to insert the Qcubed page into an article using this format:

* Usage
* {jqcubed [filepathneme] [arg1] [arg2] ... [argN]}
* where
* where filepathname is the file pathname of the file to be included - files should be located under the JQCUBED component folder
* arguments [arg1] [arg2] ... [argN] are optional. It depends on your custom included php file if it can handle them.
* Arguments can be accessed in an included file by $jqcubed array.
* Remark: everything out of the square brackets is ignored: you can use this feature for your comments e.g.:
* {jqcubed blablabla [filepathneme] width=[arg1] heighth=[arg2]}
*

I apologize if you have found the plugin "frustrating", but please keep in mind that Sebastian has generously donated his work to both the Joomla and Qcubed community. I have volunteered to help him with documentation and plan on doing a few videos explaining the install process and usage examples, but like everyone else there is sometimes just not enough time in a day.

Offline
Joined: 04/30/2008

Good i deleted my previous post before clicking the "SAVE" button.

By no mean this is the proper way to ask for help from people that have spent their time freely to provide this component.

First thing first you won't see from or panel if not previously generated that would defy the purpose.
The generated files are, as stated, generated by JQCubed in the folder where JQCubed puts them. If you look at the folder structure, you'll notice the drafts folder.

When you request from the administrative side the formdrafts or paneldrafts you will see the url being option=com_jqcubed&task=paneldrafts or task=formdrafts

From this you get that the com_jqcubed is requested (jqcubed.php). In JQCubed.php, just above the code you've specified , you'll find that paneldrafts is associated with the following:

if($option == __QJOOMLA_MODULE_NAME__ && !$task){
require_once(__QJOOMLA_LIB__ . DIRECTORY_SEPARATOR . "index.php");
}
else if($option == __QJOOMLA_MODULE_NAME__ && $task){
define('__QJOOMLA_FORM_ACTION__', 'index.php?option=' . __QJOOMLA_MODULE_NAME__ . '&task=' . $task);
switch( $task ) {
case 'formdrafts':
require_once(__QJOOMLA_DOCROOT__ . DIRECTORY_SEPARATOR . "drafts/index.php");
break;
case 'paneldrafts':
require_once(__QJOOMLA_DOCROOT__ . DIRECTORY_SEPARATOR . "drafts/dashboard/index.php");
break;
case 'codegen':
set_time_limit(0);
require_once(__QJOOMLA_LIB__ . DIRECTORY_SEPARATOR . "_devtools".DIRECTORY_SEPARATOR."codegen.php");
break;
case 'info':
require_once(__QJOOMLA_LIB__ . DIRECTORY_SEPARATOR . "index.php");
break;
default:
require_once(getFilePath($task));
}
}

... second case. Now, if you don't see the paneldrafts, it might be because the link is not pointing to the appropriate location. In your case, it seems that $task is empty.

The generated code should give you the appropriate link. If this is not the case than there is an issue that you could have brought to my attention by email way before you got angry or upset.

The way i've defined to use this component is the following as can be deducted from the switch and if statement of the jqcubed file:

Classes: Folder Classes with extension .class.php
Pages(Forms): Folder pages with extension .php
Templates: Folder Template with extension .tpl.php

The autoload will work nicely with theses folders. If you put them in any included path settings, they should also be loaded.

By the way, and just to summarize my deleted post: I've helped several people with their personal issues with this component but never heard of you. My contact information is on the web site. I'm trying to find some time to update the documentation and to add a forum.

concerning the plugin, the documentation is provided in the plugin description. It might not be as up to date as i would like it. But you could start with the default usage of the component and notify me of your issues by email.

even more than my email is provide for ... sake!!!

.... i'll stop here ... taking a deep breath ..... let me know if i can help further. Go on my web site, use the contact us form and fill it, then press SEND and if you're polite i'll help you. That's the most politically correct i can be after such an email.... sorry to the JQCubed web site for not controlling myself more than this. :-)

Have a nice day

Offline
Joined: 05/31/2009

I was not asking for help. I was stating why we won't be using JQCubed.

Both you and Allegro obviously have experience with this particular framework. Your familiarity and knowledge obscure the basic things unique to QCodo / QCubed that you had to figure out to use them.

We recognize the value of your contribution and contribute both money and code to various projects, but you needed to hear from someone who has the expertise to work this out, that in its present form JQCubed is not worth the effort unless you are already intimately familiar with QCodo and QCubed.

If you're targeting QCubed and QCodo experts, say so. Otherwise, put together a simple configuration for dummies with a simple application.

You see, without some basic documentation and a simple demo application, if one is not already familiar with QCubed or QCodo, then it is more work to figure out how to use them then to simply write the code for the needed application from scratch - with assist from a library of past projects and code.

From your responses, it looks like you have already wasted more time supporting people on basic installation than it would take to put together the simple information required for someone to get JQCubed installed and running. -- The amount of time defending your lack of documentation to me is probably sufficient to put it together.

As I said, it is a shame to put so much work into something and then not provide the basic information to make it work on a simple example -- which would demonstrate your extensive experience with QCodo and QCubed, allow Joomla folks to use it successfully, and have them singing your praises rather than cursing you for wasting their time.

Apparently, my assumption that it was trying to generate a CRUD from the entire Joomla database is correct -- Since there's an XML file where one specifies what table prefixes to exclude about which I knew nothing and therefore, excluded nothing.

It is reasonable to assume that, even though QCubed can be configured to put generated code anywhere, that in Joomla, there might be some restrictions to accommodate Joomla security and sessions - but, you didn't configure it for default folders, nor provide any guidance or suggestions. As a result, even if we got it working, we couldn't use it because of security concerns. How would we ever know if we had put stuff where it would be secure without reading every line of code generated?

We won't be using this tool on our current project - which is a Joomla application for a vertical market in which we have customers. As a result, we won't be providing any support, coding, or money to this project.

It's a shame really, since we've looked at QCubed and it appears to be an excellent framework.

Since we're on the subject, it seems like all you really need is to provide the following information:

1. How to include/exclude database tables from the code generation process.

2. A recommended default set of folder locations for generated code, etc.

3. Recommended folder and file security settings - chmod. (I got very nervous when I read in the QCubed documentation, "Since I assume you are on a development server, just make everything in the QCubed folders writable and executable by anyone.")

4. A simple application with a 2 or 3 column table, a submission form in the Joomla front-end, and a data view and edit in the back-end.

5. What "not_found.inc.php" on the panel drafts page means (Don't feel bad about that one, since neither the QCodo or QCubed documentation explains that or how to fix it. When I found it in the code, I still didn't know whether it was because I had no applications or because the pathing was wrong!)

6. Anything else basic that I might not know to mention here.

It is downright weird to see "Qcodo Development Framework 1.0.0 RC2 (QCubed 1.0 RC2) -- Start Page -- It worked! -- If you are seeing this, then it means that the framework has been successfully installed." and a CORRECT list of the file paths, urls, and database parameters -- when the installer hasn't actually set any of this up for Joomla and it doesn't tell you that this information needs to be added to the "configuration.inc.php" file. (It's not your fault that QCodo and QCubed installers do it that way, but that's not an excuse for not providing some basic information about what you have to do.) -- Especially, when you are told to "verify the database connection, add some tables, and then click the Code Generation link". I did what they said: I looked at the database parameters listed on the page - they were correct, added a couple of tables for a sample application, and clicked the Code Generation link. I got a blank page with no error messages.

YOU would not make the mistake I made because you already knew that the information listed had to be added in to the configuration file.

It's obvious that, with your knowledge, you could create simple documentation in 15 minutes, maybe 30 if you wanted to format it nicely. That little bit would literally save every person who wanted to use JQCubed hours of reading code, reading documentation, and trial and error to get JQCubed working.

I'm sorry that you feel attacked and unappreciated, but I will not apologize for picking on you for the reasons I've stated. You might want to think about whether you want people to use JQCubed or whether you're doing it for your own entertainment and sadistic pleasure.

We won't be using QCubed or JQCubed for our current set of projects, but I am still interested in it for the future and would like to familiarize myself with it.

I won't take you up on your offer of private support via email because that won't solve the problem for anyone else. However, if you put together the basic documentation, I'll use it and provide corrections and feedback to make it crystal clear and easy for others. -- Which will make better use of your time than providing individual support.

As an aside: The biggest pitfall I see in any development project is that the programmers know the system so well that they forget to mention the very basic things they can jot down in 5 minutes and thereby save others hours. Back in the 70's I was using StarWriter on a pc (it was CPM operating system, I think). I wrote a letter and then discovered that I didn't know how to save it. The "save" command was not in the StarWriter documentation. I'm stubborn, so I wasted 2 hours looking for the information before I broke down and called the vendor to ask. Another time, I was creating an extract which contained a subset of the fields on all of the records in a file using a report-writer / file utility. My output file kept coming out fried. It took two days and half a day from one of the systems programmers to figure out that the word "edit" needed to be included in the command file to change the record and blocksize on the output to match the new record size.

OOPMan's picture
Offline
Joined: 11/07/2008

QCubed does have quite a few rough edges. Joomla, on the other hand, it just plain ol' crap.

Offline
Joined: 05/31/2009

OOPMan said,

"QCubed does have quite a few rough edges. Joomla, on the other hand, it just plain ol' crap."

I won't agree that JOOMLA is crap since I'm not aware of another Content Management System I could use effectively for my purposes.

So, OOPMan, my question for you is this: What alternatives are available to Joomla that meet requirements listed below? (This is NOT a rhetorical question. We've used various nuke-like CMS's, Drupal, and a few others over the years, and JOOMLA, warts and all, is the best platform we've found so far -- which may not be saying much from some perspectives.)

Some requirements:

  1. Free or close to it because a lot of the work we do is for small non-profit organizations that may (hopefully, with our help) be bigger non-profits, but who simply do not have the funds for an expensive solution at this time.
  2. Is relatively easy to train volunteers to access the system for maintenance, to fulfill patron requests, etc.
  3. Has a wide variety of extensions for various tasks.
  4. Is reliably supported on a LAMP platform (well, it doesn't really have to be PHP, but the choices beyond that are limited.)

I do understand your concerns with Joomla, especially from an OO perspective. Back in the late 80's I developed my own technique for OO Analysis, Design, and Programming. It was centered around traditional data-modeling, and relational database normalization, and used the Glockenspiel C++ compiler as a CASE tool because at that time there were no OO CASE tools. I taught designers and programmers building new peer-to-peer applications with GUI's on OS2 Presentation Manager, and back-ended by IBM mainframes, Linux servers, Tandem, and various other platforms. My customers were people like IBM, American Airlines, Coca Cola, Blue Cross / Blue Shield, Motorola, Swiss Bank, and Grumman Aircraft.

IBM and some of the software companies with which I worked still market products that started by my training a development team and leading the project until they had a complete set of objects and messages defined in the C++ compiler. They would then complete the project by writing the application code that went inside the objects.

Anyway, I would be thrilled to know of a realistic alternative to Joomla.

Offline
Joined: 04/30/2008

What you need to understand hostricity is the following:

JQCubed is a component that i've made and it has nothing to do with your opinion of QCubed or QCodo.

JQCubed is not responsible for the documentation of the framework and for training you on it.

You made a bad review on the Joomla extension website about something that the component is not responsible for.

Other points: all the users have learn with the examples site the light documentation (THAT is true) and with the forum.
The forum is where decent people ask decent question about the framework without bitching at the world.

If you would have asked for help, i'm sure people on this site and/or Qcodo's forum would have been happy to help.

if there's something that is plain old crap here it's your review on the joomla's web site!

Offline
Joined: 04/30/2008

I do not agree with you concerning joomla!

For me , joomla 1.5 or Drupal the choice is easy: Joomla by far!

That being said i would not say that Drupal is plain old crap, i would say, it's your choice and opinion and i will respect it but do reconsider Joomla.

The only thing that is plain ol' crap is your statement! I don't like Drupal, and not at all, but it doesn't mean that Drupal is plain ol' crap! It simply means that you made the wrong choice ahaha!

Some people are funny, should read recent review on Joomla vs Drupal.

No offense, but you know what your statement sounds like:

I've made the wrong choice, don't want to admit it and too much work to switch to joomla so now i'm convincing myself that joomla is crap without any reasons !!!!

ahahahahaha!

alex94040's picture
Offline
Joined: 11/06/2008

Folks - I encourage you to keep the discussion respectful and constructive. Don't call others' work crap, ever. Even if you really think it is. No one wants to be on the receiving end of that.

If there are things you don't like, list them, and politely ask for help. This is an open source community - nobody is obligated to help you. You aren't paying anyone for help. Folks who are answering your questions are doing so out of the goodness of their heart and their care for the QCubed community.

On a somewhat related note - I know of many folks in the QCubed community who use Drupal extensively. There was a Drupal plugin to integrate with QCubed.

OOPMan's picture
Offline
Joined: 11/07/2008

With regards to Joomla itself being crap there's really not much to say. Joomla is a CMS, like Drupal. It's built with a fairly specific kind of site in mind. The problem is, the developers of Joomla and Drupal really want people to use their CMS system to build all kinds of systems.

The problem here is that the inevitable result is a CMS hacked to death in order to try and jerry-rig it to work as something else (E-commerce system, wiki, blog, etc, etc, etc).

A lot of the time half the problem with a website is that it was originally developed inside of the context of Joomla/Drupal.

For me, the difference between building a site within a framework (QCubed, Zend, Kohanna, Symfony, Cake, etc, etc) and a CMS (Joomla, Drupal) is that the latter implies a certain idea of what the site is that is not always relevant and thus makes development problematic in a lot of instances.

Joomla and Drupal are popular because there is a large body of people out there who desperately want to believe that web application development is somehow intrinsically simpler than desktop application development and that all web problems can be solved with a single tool (Joomla/Drupal). This idea is horribly flawed. Web application development is not intrinsically simpler than desktop development. It can seem so, because the amount of time required to produce an UI skeleton in the web application context is lower, but this is not truly the case. Once it comes down to the implementation of actual business logic and rules a web application can be just as complex, if not more so, than a desktop application thanks to the idiosyncracies of web develpment.

Finally, I am in no way dismissing the work of QCubed Joomla integration group or the QCubed Drupal integration group. I'm glad that people are working on QCubed related code. Nevertheless, I think that the use of Joomla/Drupal as a kind of magic web application balm is a huge problem in the web development world and responsible for a lot of troublesome maintenance woes.

Offline
Joined: 05/31/2009

OOPMan:

After calling Joomla "crap", I note that you haven't offered a CMS you think is better.

To me, using a framework like QCubed with Joomla is a great way to take advantage of basic website functionality (Joomla) and add site / business specific functionality using a framework like QCubed.

I suspect that we'll eventually see a complete CMS built-in a framework like QCubed and that will make adding the site / business specific functionality that much easier.

The biggest problems, as I see them are:

The CMS's are pretty much hand-coded, don't take advantage of database constraints, stored procedures, etc. to reduce the lines of code, and are not really built on a data-model conducive to code-generation.

As a result, what we have is a basic registration system which is not integrated with the contact system which is not integrated with things like memberships, newsletter subscriptions, tracking patron requests, sales records, etc. -- without a lot of pain and hassle. Essentially, the CMS becomes a collection of separate database entities that duplicate data and require complex code and bridges to keep the data synchronized.

Theoretically this would be avoided by a CMS that was generated using a framework like QCubed so that integration of the things mentioned, would not be an issue.

The approach we are taking is to use Joomla for what it is really good at doing: to layout the website and publish information. We are planning to not use the Joomla registration or contact system, at all. Instead, we will build that using a framework so that everything pertaining to site visitors and members is fully integrated. The Joomla user system will only be used to provide administrator userids for publishing news, etc. and to gain access to the Joomla control panel where the admin aspects of the application framework will be used. We will be using modules and plugins to publish the framework specific forms and data views.

This seems to be the best compromise short of coding the whole website in the framework. As we see it, the basic publishing function is not directly related to the business data in any way that's of much importance.

That's why we were looking at JQCubed. For the moment, we will be using a Windows or Linux code generator off-line and then publishing the generated code in Joomla, rather than doing the code generation within the Joomla admin console as JCodo and JQCubed do it. Site administrator functions will be placed in the Joomla admin console.

In fact, we may even use QCubed as our framework - but we'll simply be publishing the generated code to Joomla rather than generating the code in Joomla. I've tasked someone to look at whether there's any advantage to using Joomla as a development tool with JQCubed and then publishing the generated code to a production Joomla website that can execute the generated-code but cannot generate it. -- I'm not convinced there's any advantage to generating the code within Joomla. Of course, I may be wrong, so we're looking at it both ways.

Offline
Joined: 05/31/2009

Basdub:

I simply disagree with you.

I like QCubed just fine. It is a sophisticated development tool to be used by sophisticated developers.

You have created a way for QCubed to be used within Joomla. The Joomla audience requires a "hello world" example that is included with the component in the same way that Joomla provides the sample database - so that people without the expertise to do the research, digging, or even to formulate the correct questions for the forum, can get something working they can build on.

Frankly, I was shocked. I've used all kinds of Joomla and Drupal components, as well as components for nuke, phpwebsite, plone, and other CMS's and I've never seen a component that I couldn't get working within 5 minutes of installing it - and without much digging. That is, until JQCubed.

If you choose to think I am not a "decent" person because I disagree with you on this, that is really your problem not mine. I simply felt that those who were considering using JQCubed needed to know that it requires a level of sophistication and a knowledge of QCubed or QCodo to get it working successfully.

As I have stated previously, you could have written the basic documentation to get it working in less time than you have spent attacking me and defending yourself. I haven't called you names, nor have I called anything "crap." I don't think you would be so angry and defensive if you didn't know that I have done nothing more than offer valid criticism which you don't want to accept.

I also note, that I offered to troubleshoot and correct any documentation you might write and you have chosen to not take me up on that offer.

By the way, the link to the wiki in your description of JQCubed on the Joomla website is a dead link.

OOPMan's picture
Offline
Joined: 11/07/2008

hostricity, I didn't offer an alternative CMS to Joomla or Drupal because I am of the opinion that CMSes are, for the most part, less than useful.

They work okay for small sites with very basic requirements. However, when you need a site that isn't a CMS or is is a superset of a CMS (e-commerce, etc, etc) then it is better to build a custom site than hacking a CMS to try and do the job.

Or, to put it another way:

The awful code underlying most CMS systems quickly becomes a problem when you're trying to do complex work and extend said CMS to function in some extended fashion or other.

Offline
Joined: 07/07/2008

My 2 cents.

I used Joomla, developed components intergrated the authentication with the Active Directory. Joomla is the classical application written without any real serious architecture, even thought the components are know MVC. Drupal, it think is even worse than Joomla.

By using Qcodo and then Qcubed, I realize how much is horrible to develop with that CMS. Of course they are full of features and pretty handy.

CMSs of higher level are EzPublish and Typo3. EzPulish is an enterprise CMS, with a serious framwork behind. I do not know Typo3 at all never install.

If I have to choose one know, I would choose EzPublish.

It is very good that we have a component for Drupal and one for Joomla but the documentation is inexistent. The same applies to Qcubed, not any serious documentation.

Offline
Joined: 05/31/2009

Not to be stubborn, rtacconi...

We are having some success with using Joomla as a content publisher and not using the registration system or contact system at all -- Except that we use it to register admins and give them permissions. For many websites, Joomla works great as a publishing system. This function is well-enough known, that I'm not sure exactly what you get by implementing the basic CMS functionality in a framework that would cause us to abandon Joomla in favor of a framework-designed and architected CMS. (I've worked with EzPublish before and found that it is difficult to deal with and confusing for website admins and content publishers in a way that Joomla or Drupal is not.)

When user registration is required, we'll use our own application that is properly designed so that the login, user profile, and business data on that user are part of well-designed database rather than using synchronizers and bridges to tie extensions together. (Now, here's where designing a CMS with a framework would make a difference. It would mean that the Joomla registration and contact system wouldn't be separate systems - they'd be part of a user management component that could be extended through a framework instead of hung off the side.)

We are experimenting with building applications using QCubed, CAKE, and a few other code-generation tools and then using Joomla to display the forms, data views, and CRUD in the Joomla front-end and administrator control-panel as appropriate to the application.

We won't be generating application code from within Joomla, but we haven't figured out yet whether JQCubed helps us with publishing the application on the front-end or in the administrator control panel.

Our thought is this: If you can do it with ChronoForms / ChronoConnectivity, then generating the code within Joomla is OK, but anything more complex shouldn't be generated by a webmaster or admin, and doesn't need to clutter up the Joomla administrator control panel.

I'll let you know as we proceed, how this works out.