Thread

Hi everyone!

I just created this library for myself and it still needs some work, but it’s a good starting point. I thought someone could be interested in it and if you have any idea or complaint please post it here!

[DESCRIPTION]
This is a true light-weight customizable scaffolding/crud library. It’s very similar to Scaffolding class natively provided by CodeIgniter except that it allows you to customize all the elements.
Please read the user guide in the -doc- folder.

[NOTE]
This library is at a very early stage, so please don’t expect it to be something complete.

[DOWNLOAD]
CRUD 0.1
CRUD 0.2 (2008/02/24)

Hi suashi,
I am new to CI but I like your move.
I was in search for a crud model, or something similar.
I also wanted to be very simple and integrated very well with CI.
Personally I liked what David Upton says in his book “Loose Coupling & Component Singularity”.
And for a scaffolding/crud library I don’t need Code Crafter or similar applications which I have to read another
manual to understand its mechanisms.

Cheers

Thanks Atasa for your reply, you completely got my point of view about keeping stuff simple!

Btw…

I’d like to use this post to spend some words about why I’ve done CRUD.
I used Rapyd and CodeExtinguisher and they’re both fenomenal, they really cut down your development time and I don’t want to say that CRUD library is more advanced than Rapyd or CodeExtinguisher, absolutely not… but:

- I love EXTREME simplicity and ease of use
- I don’t want tons of files and folders
- I don’t want to hack a library to suit my needs (it should be very open minded out of the box)
- I don’t want to delete all the unnecessary stuff like fancy js or similar
- I don’t want to use hacked libraries from CodeIgniter so I can easily update the core

So basically I ended up with a structure (based on 1 library file, 1 folder with the fields, 1 language file) which doesn’t force you to learn anything at the beginning, because it works like CodeIgniter’s scaffolding with only one line of code; then if you want to have a different behavior you can start reading the simple manual and begin your customization which is very easy like declaring some array values.

Now I’m about to release a version 0.2 with some enhancements, a better form layout for the example and some more fields.

I really hope you guys can give me some more feedback about CRUD!

Cheers,

gyo

Hey I agree absolutely,
One thing I have to express tho..
I sat down and figure out that the only thing I need for myCRUD is 2 library files that are completely agnostic
from the other application, which just return data.
So for Start I try to implement
1. Data Form builder class library (loads->helpers->url,form,html)
2. customizable Datagrid table class library (loads->helpers->url,html, loads->library->table)
3. Data Model (All sql logic is here and just binds data to Form Builder and Datagrid which return xhtml formed code)
model class extends->Model

So in this case don’t actually need to say &get;instance() in my library and can change any of this files any time
without any worry.

Cheers

PS
I forgot the Language part which i thing is very important not only for different languages
but also to just keep the standard wording separate.
But I haven’t got so far and i like your approach in to that too.

Now I’m about to release a version 0.2 with some enhancements, a better form layout for the example and some more fields.

I really hope you guys can give me some more feedback about CRUD!

Cheers,

gyo

Hello gyo: your CRUID project is very useful; me also, i am an Rapyd user….Do you release a frame field in your future crud version?

Now I’m about to release a version 0.2 with some enhancements, a better form layout for the example and some more fields.

I really hope you guys can give me some more feedback about CRUD!

Cheers,

gyo

Hello gyo: your CRUID project is very useful; me also, i am an Rapyd user….Do you release a frame field in your future crud version?

Actually I didn’t think about a frame field, but I’d like to invite everybody who is interested to collaborate!

Btw… thanks guys for your feedback, it really stimulates me to go on with this project!

Hey I agree absolutely,
One thing I have to express tho..
I sat down and figure out that the only thing I need for myCRUD is 2 library files that are completely agnostic
from the other application, which just return data.
So for Start I try to implement
1. Data Form builder class library (loads->helpers->url,form,html)
2. customizable Datagrid table class library (loads->helpers->url,html, loads->library->table)
3. Data Model (All sql logic is here and just binds data to Form Builder and Datagrid which return xhtml formed code)
model class extends->Model

So in this case don’t actually need to say &get;instance() in my library and can change any of this files any time
without any worry.

Cheers

Pretty good!
I like your idea to separate form builder and data model, please let me know!

thanks,
gyo

This is interesting.  Looks very flexible.  Take a look at ATK’s idea of “attributes” for more ideas

http://www.ibuildings.nl/wiki/ATK_Attributes

ATK is a fairly large monolithic framework. 

The trouble with CRUD is that when you get focused on widgets you end up developing stovepipes (your data and functionality is sunk in there,  and you’re dependent on the CRUD for whatever limited displays it has).

What I’d like to see is a CRUD that defined SOA endpoints instead of generated web pages.

That way you could lightweight clients like built with EXTjs,  or a sharepoint web part, or something,  that could then communicate with your CRUD by exchanging small documents.

Error messages etc could be passed as part of the document, in the case of loosely coupled data entry forms with the CRUD server.

The basic design of ATK is “module” containing of one or more “nodes” (point to table basically) containing one or more “attributes” (field level mappings).  It’s very flexible and very good at mapping to legacy (though this is not always necessary,  there is another enterprise pattern that doesn’t integrate directly into legacy systems,  but gathers stuff,  then forwards messages into the system,  a CRUD mapper is not the correct choice for this,  I can say after having made the incorrect choice 😊

I think ATK’s design is sound.  But I want to remove the HTML half and just have it deal with XML/JSON exchange.  It does no good to replace an Oracle Forms stovepipe with a PHP Forms stovepipe.  It costs the same and it’s all in one place.  The cost of these things needs to be distributed.  Strategic.

There,  have said too much,

-Rich

Hi kucerar!

ATK is quite advanced and has a very complex structure, and I already found some inspiration… thanks!
I’m implementing a ‘post’ method in the fields if you want to execute some callback, and the output should make a difference between form and error messages…
I thought about mapping the scheme of a table too, or creating the crud from a definition file, but I want… KISS!
:D

Let me say It’s really my intention to abstract the output, but I think that at this stage it would be a bit premature since the library is very young and focused to extreme simplicity.

Btw I think that in a couple of hours or less I’ll post a 0.2 version…

cheers,
gyo

.......
but I want… KISS!
:D
.......

Isn’t that the main reason why we all chose CI over all the other frameworks in the first place? 😉

Looking forward for 0.2!

Hey guys this is getting interesting…
My point of view is that we can discuss different ways and alternatives for ever.
Lets start from what we have already.
We have CI.
Then we check whether is OK this tool to work on.
Remember this is not an easy job.
I have looked for quite sometime now in frameworks, html generators, template systems etc.
The first thing that clicks to your mind when you see a framework is the philosophy it is based on.
If we have decided to use CI so lets see how far we can go, and if that is expensive too. 
I also thing that some logic sould go also at the database it self.
One good example is the mysql database in MySql.

suashi you can try the following as well:

<?php

class Welcome extends Controller {
    
    
    function Welcome()
    {
        parent::Controller();
        $this->load->library('table');
        $this->load->helper('form');
        $this->load->helper('url');    
        
    }
    
    function index()
    {
    
    $form = array(
        'Row1' => array(
            'FIELD_NAME' => 'field1',
            'FORM_CAPTION' => 'Text for field1',
            'DEFAULT_VALUE' => 'enter text here',
            'EDIT_TYPE' => 'input',
            'LOOKUP_COMMAND' => ''
        ) ,
        'Row2' => array(
            'FIELD_NAME' => 'field2',
            'FORM_CAPTION' => 'Text for field2',
            'DEFAULT_VALUE' => 'Please make a Selection',
            'EDIT_TYPE' => 'select',
            'LOOKUP_COMMAND' => array ('key1'=>'value1','key2'=>'value2','key3'=>'value3')
        ) ,
        'Row3' => array(
            'FIELD_NAME' => 'field3',
            'FORM_CAPTION' => 'Please write your Details',
            'DEFAULT_VALUE' => '',
            'EDIT_TYPE' => 'textarea',
            'LOOKUP_COMMAND' => ''
        )
    );

    $oform = form_open('email/send')."\n";    
    $oform .= $this->table->set_heading('Name', 'Value');
    
    function BuildForm($myform)    
    {
        $mytable = &get;_instance();
        foreach ($myform as $array)
        {
            switch ($array['EDIT_TYPE'])
            {
                case 'input':
                $options = array('name' => $array['FIELD_NAME'], 'value' => $array['DEFAULT_VALUE'], 'maxlength' => '50');
                $mytable->table->add_row($array['FORM_CAPTION'], form_input($options));
                break;

                case 'textarea':
                $options = array('name' => $array['FIELD_NAME'],'value' => $array['DEFAULT_VALUE'],'rows' => '7','cols' => '50');
                $mytable->table->add_row($array['FORM_CAPTION'], form_textarea($options));
                break;

                case 'select':
                $mytable->table->add_row($array['FORM_CAPTION'], form_dropdown($array['FIELD_NAME'], $array['LOOKUP_COMMAND']));
                break;                                
            }
        }
    
    }
    BuildForm($form);
    
    $oform.= $this->table->generate();
    $oform.= form_reset('myreset', 'Reset Fields');
    $oform.= form_submit('mysubmit', 'Submit Post!');
    $oform.= "\n <br>" . form_close() ;
    echo $oform;
    }//endIndex
    
    
}
?>

It’s small sample of binding an array to a form generator class.
for the sake of the example I have created a subfunction and used &get;_instance() method.
you can just run it by it self and see the results.

Very easy right?

What do people thing about using table layout for forms? Me personally, I don’t think you should. A table is for displaying tabular data, a form isn’t this. It also means you can’t easily change how the form looks. E.g move the field name above the input box instead of it being to the left.

What do people think? Coz I think this is a major point of having a customizable CRUD system.

I have to agree with adamp1. Customizable means views too. But a simple solution would be to work with partial views.

You could even go as far to having a separate views for each type of form field. That way you can create your own form elements. With it then being able to handle dynamic data that would be quite powerful (IE adding descriptions to a field value). Suppose best form of crud would be to output it to files so you can tweak it.