Hi, after some thoughts I'm still far from having a clear idea about what to put in a dbtng example module. There is enough documentation in the API and in the documentation.

So, I need help designing a script of this module. I have no idea what to include (using several databases? perhaps?) that could be tested easily not requiring additional setup or complex configurations.

Help or Chim!!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rfay’s picture

I think just a working example with tests that does CRUD functions and maybe 3 or 4 other things that an average developer might like.

In this case, the comment could show the old way, and the code could show the new way.

A nice structure might be a simple form that gets its defaults from a db, writes to the db, has an option to delete.

And maybe there's one or two other things that are must-have for dev other than CRUD.

The idea is not to compete with the docs, but to put in the developer's hands a working model to play with.

ilo’s picture

Assigned: Unassigned » ilo

Thanks rfay, I know you told that same answer too many times, I should be able to do 'that' simple.

ilo’s picture

Status: Active » Needs review
FileSize
9.26 KB

Ok, first draft.. I've written some of the functions using the database, the module has no interface yet, but this is just a helper.

Please, take a look and tell me something, I'm unsure if I'm doing right.

ilo’s picture

FileSize
2.22 KB

The .install file I forgot to include..

bg1’s picture

I am a Drupal newbie so maybe my comment is off base, however, I believe a major purpose of training and examples is to help newbies become proficient using Drupal in various ways.

A major challenge I see with many modules, is that the module documentation focuses on what the module does and not how to integrate it into Drupal in a meaningful way.

For example, regarding database interaction, being able to integrate the query is one thing, but how does one integrate this with the View module so that one can have the results of the query feed into the view module. In other words, I want to be able to say that the View module executes a query against a remote non-Drupal database and have the View Module process create the display aspects of the results of running my query as if it were a Drupal database query.

The same could be said for integrating queries with forms. I want to be able to define a form that hands off to my query which will insert/update data in a remote database. showing how to do that in a tutorial would be good.

Regarding database specific aspects, are their any constraints regarding the use of stored procedures? I tend to do all my database queries in stored procedures and only allow programs to execute the stored procedures.

I guess the bottom line is there are a relatively small number of Drupal users who are knowledgeable about every aspect of Drupal and would be satisfied with a very narrow tutorial that shows only those aspects pertaining to the module or API at hand. I suspect most, however, would benefit from guidance that includes not just the specific module/API, but also how to integrate it into the Drupal framework.

Just my 2 cents.

Bill

bg1’s picture

Ilo,

Congratulations on your taking ownership of the SOAP Client project.

I am strongly interested in such functionality and in building generic modules to enable Drupal implementations to be front-ends to remote back-end applications and databases.

I have a strong background in database, overall system architecture, framework design and development, etc. and may be interested in participating or at least exchanging ideas to advance such efforts.

How can I contact you or others involved in that project to learn more about where you are and perhaps exchange some ideas for that module? (I am a Drupal newbie and do not know how to interact with projects or project teams.)

Thanks.

Sorry to everyone else on this issue thread for posting something off topic.

rfay’s picture

@bg1 - thanks for the notes.

You can catch ilo on irc or by his contact form.

What I hear you saying in #5 is that you'd like the examples to be more rounded. Have you looked at the email example, or the AJAX example? Do they meet your needs? Is that what you're talking about?

We probably won't do contrib in this module - I think views needs a completely separate views_examples module.

jhodgdon’s picture

Regarding #5, I think it's better to have small, modular examples, each showing a small piece of what developers will need to do. I.e. a module on how to do X, a separate one on how to integrate stuff with Y, rather than a big example that shows how to do X, integrate it with Y and Z, etc.

The reason I think that is because everyone will need to do different types of integration (put different pieces together), and it's a pain to have to read through a huge example to find the little bit that you need for your purposes. We have a fully-integrated example (Drupal itself and all its contributed modules)...

ilo’s picture

FileSize
22.35 KB

Hi, I agree with jhodgdon and rfay, almost every module could be considered an example, and making a sepparated "views" example seems to be better than include specific "views" code in a module for developers who never used it: as a learning example, how would they realize that piece of code for views in not required?

On the other hand, having a database example module including code for 'views', then 'profile', why not 'blocks'? and don't forget 'node_access' would become useless.. when do you think the list would end? it is impossible to maintain, even to read.

bg1, Well, you have an advantage being new to Drupal, you are in the best situtation to test and evaluate if the examples modules are usefull or not :)

Focus on the issue purpose.. I've included a little testcase, nothing really usefull I'd say, just tests that module pseudo-api functions using dbtng are working.

The module now includes two list views (nothing to do with views module) making use of db_select():

  • a simple list with all the fields of the database table
  • a more complex one, with a join to users table
  • The form only allow adding new entries, using db_instert().

    db_delete() and db_update() are included and documented in the pseudo-api, but there is no form neither link or button that calls them.. why? because It just over-complicates the module code. IMO, if someone is unable to understand how to make a call to dbtng_example_entry_delete() from its own code, the problem is not learning DBTNG, but learning how to make a menu entry.

    OT: Thanks for your offtopic comment, gb1, that project has its own issue queue where you can open any 'task' or 'support' ticket you need. As rfay mentioned, I'm also available by other ways.

    rfay’s picture

    @bg1, one more thing: Drupal is a do-ocracy. So you're welcome to contribute to this project. Create the module that you think would help people the most.

    We can at least open up a contrib subdirectory!

    rfay’s picture

    Assigned: ilo » Unassigned
    FileSize
    27.14 KB

    OK, here's a big round. I added updates, more tests, more documentation.

    Very interested in reviews.

    rfay’s picture

    Status: Needs review » Needs work

    Per Crell's comment in http://drupal.org/node/508342#comment-2082294, it looks like we shouldn't be showing the usage of db_write_record().

    rfay’s picture

    Status: Needs work » Needs review
    FileSize
    25.01 KB

    Here is a reroll with the db_write_record() references removed. It's simpler, and that's good.

    rfay’s picture

    Status: Needs review » Fixed

    Passed the bot, and I'm committing it: http://drupal.org/cvs?commit=326686

    Patches to improve this, or opinions about it, are welcome.

    Status: Fixed » Closed (fixed)

    Automatically closed -- issue fixed for 2 weeks with no activity.