- QDatepickerBase.patch attached to Ticket #847
- Ticket #847 (QDatepicker does not supports "-1d" or "+1m" syntax for minDate/maxDate) created
- class_load_and_count_methods.patch attached to Ticket #846
- Ticket #846 (Over-optimization in codegen for cache key creation) created
- Ticket #845 (QDialog rendering events problems when modified) updated
There are currently 1 user and 5 guests online.
Theme developed by
pM
using entirely open source solutions.
No it does not. The code generator is driven by the database field types and there is no image type. The closest would be a BLOB, but that does not give you an image uploader.
That does not mean it cannot be done. It just won't be auto-generated. You can try and override the associated create_YourControl function in includes/meta_controls/YourClassMetaControl.class.php. You will find the generated MetaControl class in the subdirectory includes/meta_control/generated. Have a browse through the generated class and you will see what I mean.
Cheers
Helge
Thanks so much guys. I will test this out. It's great to have an active community for any open source framework.
Once I'm done with the learning curve I look forward to contributing myself. ;)
When an object is printed it will display using its __toString method. Just change that method to return output you want.
Change this function in your /includes/model/Person.class.php
public function __toString() {return sprintf('Person Object %s', $this->intId);
}
To:
public function __toString() {
return sprintf('%s %s', $this->strFirstName, $this->strLastName);
}
Or something like that.
Hello LinuxLover,
This behaviour is caused by a default __toString magic function in your RDBM classes. To solve this, go to the class 'Person' in includes/model. There you find a function definition for __toString() that looks like this:
<?phppublic function __toString() {
return sprintf('Person Object %s', $this->intId);
}
?>
Change that to something like:
<?phppublic function __toString() {
return sprintf('%s %s', $this->strFirstName, $this->strLastName);
}
?>
or whatever you prefer.
Cheers
Helge
Hmmmm.... yeah I forgot that QControlBase is the one which should not be... my bad :P
Those classes are meant to be modified.
/*** QControl.class.php contains QControl Class
* @package Controls
*/
/**
* QControl is the user overridable Base-Class for all Controls.
*
* This class is intended to be modified. Please place any custom modifications to QControl in the file.
* The RenderWithName function provided here is a basic rendering. Feel free to make your own modifcations.
* Please note: All custom render methods should start with a RenderHelper call and end with a RenderOutput call.
*
* @package Controls
*/
Wouldnt it be better if he would rather Create a derived class than modify the core? Upgrade would erase those changes!
You could also write your own Rendering function in QControlBase and call it. \includes\qcubed\controls\QControl.class.php
Yes... that one is better :) I use it often too :D
Turns out what worked for me is just turning RenderWithName off and using Render, and then creating div elements around different fields in my template file.
Simplicity is it's own complexity? ;)
Hello Vaibhav,
I have done as you've suggested, though it didn't help. Maybe I was not very clear in the initial description of the issue. Here it is again...
The autogenerated code for Users metacontrol Create method is:
public static function Create($objParentObject, $intId = null, $intCreateType = QMetaControlCreateType::CreateOrEdit) {
// Attempt to Load from PK Arguments
if (strlen($intId)) {
$objUsers = Users::Load($intId);
// Users was found -- return it!
...
what bothers me here is there is no way of defining that this object should be only able to be created, without possibility for executing "Users::Load()" line. (we don't want to be able to read data from DB to website through registration form)
One way to get over this is to overload the User's Create method in non-autogenerated MetaControl file to behave like:
public static function Create($objParentObject, $intId = null, $intCreateType = QMetaControlCreateType::CreateOrEdit) {
if ($intCreateType != QMetaControlCreateType::CreateOnly) {
// Attempt to Load from PK Arguments
if (strlen($intId)) {
$objUsers = Users::Load($intId);
// Users was found -- return it!
if ($objUsers)
return new UsersMetaControl($objParentObject, $objUsers);
// If CreateOnRecordNotFound not specified, throw an exception
else if ($intCreateType != QMetaControlCreateType::CreateOnRecordNotFound)
throw new QCallerException('Could not find a Users object with PK arguments: ' . $intId);
// If EditOnly is specified, throw an exception
} else if ($intCreateType == QMetaControlCreateType::EditOnly)
throw new QCallerException('No PK arguments specified');
}
where QMetaControlCreateType::CreateOnly is added in the In file: includes/qcubed/_core/base_controls/_enumerations.inc.php
What I would like to ask is should such a change be created as ticket (to modify the autogeneration template and the Qcubed framework), or there is another more inteligent way of using autogenerated code for object creation only?
(I hope everyone understands why reading data from Users table through PK in the registration form on production site is a bad idea ;)
Hope it makes more sense now...
In the drafts edit files, comment out the lines which perform the render of the 'delete' button. That would do it!
@Linux lover: What DB are you using? If you are using MySQL then rearrange the columns and re-codegen. QCubed drafts will follow.
If you are not willing to do that and want something else, do see the formbase classes for that (the List files) and rearrange the columns as they appear. Remember that on re-codegen, the files in the formbase classes directory will be over written. So you might want to secure them at another place.
Regards,
Vaibhav
I do not know if it wanted to answer? Whether it be right for you: http://trac.qcu.be/projects/qcubed/wiki/StylingTutorial ...
You might also look at http://qcu.be/content/video-screencasts and whether this link will give you the answer http://qcu.be/files/screencasts/qcubed_mvc/screencast4.html ?
Steven,
Thanks. I will try this and let the community know if this works well (with code generation as well).
Nothing much sir, Just created something like:
<?php
class HtmlPrinter {
public static function AddCssCode ($strPath) {
echo '<link rel="stylesheet" href="'.$strPath.'"/>';
}
?>
And then call them instead of including the header.inc.php.
Keeps things in control and makes it easy to add and remove included files on the page! :)
BTW, I am thinking of writing a Cacher class which could actually reply with cache control headers for files on the system. But I am not too familiar with the protocol. Some suggestions would help.
Regards,
Vaibhav
Good answer, but how did it. We want to hear :)!
I created my own classes for that purpose.
You could look at QPage in the plugins http://trac.qcu.be/projects/qcubed/wiki/plugins. There is discussion about it here http://qcu.be/content/qpage-class.
You could try something like:
amenities
_________
amenities_id
....
resorts
_______
resorts_id
....
amenities_instance
__________________
amenities_instance_id
amenities_id
onsite_type_id
....
resorts_amenities_instance_assn
_______________________________
amenities_instance_id
resorts_id
Never mind. I knew, as soon as I made a post, I would figure it out.
Thanks.
thanks a lot!
I have the same problem if creating child like that:
<?php$btnObject = new QLinkButton($this);
?>
But no problem in this case:
<?php$btnObject = new QLinkButton($this->pnlObjects);
?>
in both cases I'm clearing panel like that:
<?php$this->pnlObjects->RemoveChildControls(true);
?>
Problem Solved !
After reading the recommended sites and googling several hundreds of the same question, I finally searched in QCodo forums to take a roundtrip to the QCubed wiki.
A simple addition to prepend.inc and to configuration.inc, as described in
trac.qcu.be/projects/qcubed/wiki/Unicode
solved my problem!
Now on with qcubed !
Thanks!
I've been the one mainly cleaning up the spam post. What I have noticed is the accounts are usually setup 2-3 weeks before the first post. My suggestion in the past was to setup a cron job that would delete any new account that has the login status of "never" for over two weeks. This would do two things, one keep the user list manageable and two, hopefully, delete the accounts before the spammers come back to use them. I would think that most legitimate users would login sooner than two weeks after setting up their account.