What is a list of checked checkboxes called with same name to cfc?

[Newsgroup_User]

Hi,

If i have say a list of user roles as checkboxes in a form and 2 or 3 of
them are checked, what would I call that as a data type in cfargument
in a cffunction inside a cfc?

Also, Can I wrap 2 or 3 separate database interaction functions inside a
cftransaction tag in the calling cfm page and have the cftransaction
work as expected if one of the functions fails for some reason?

Please excuse the newbie questions...

Kind regards,
Mark.

[Daverms]

Hi,

Q1) The datatype should be the same that you have with your database.


Q2) You want to have all your sql statements executed eventhough one (or) some of them fails?. Please clarify.

[Newsgroup_User]

Daverms wrote:
> Hi,
>
> Q1) The datatype should be the same that you have with your database.
>
>
> Q2) You want to have all your sql statements executed eventhough one (or) some of them fails?. Please clarify.
>

Hi Daverms

What I mean is that I'm trying to follow the latest "trend" of putting
all database queries into a cfc. So, say I wanted to add a user to a
system where there was first a function to add the user, then a function
to assign the roles into a many to many table via the checkboxes
selected in the registration form. My question is, if I put those 2
database functions inside a cftransaction block, will that cftransaction
work as it would if I had done it the old fashioned way, like putting
the queries themselves in the cfm page inside the cftransaction block?
Am I being a little more clear now?

As for question one.... what datatype would I choose for cfargument to
accept the list of values chosen from the checkboxes selected? I can't
seem to get it to work with any of the possible selections for data type
in cfargument..

Many thanks for your reply.
Mark.

[Daverms]

Hi Mark,

Thanks for the clarification :-)

Q2) It seems you want to put separate cffunctions inside a cfc to do the CRUD. So here the <cftransaction> will work the same old fashioned way and there wont be any issues.


Q1) Your <cfargument>'s type attribute should be matching your table's target field's datatype, that is lets assume you have a table named "users" and storing the roles in a field called "roles_assigned" which is of integer in nature, then you should declare your <cfargument> with the same datatype.

[Newsgroup_User]

Daverms wrote:
> Hi Mark,
>
> Thanks for the clarification :-)
>
> Q2) It seems you want to put separate cffunctions inside a cfc to do the CRUD.
> So here the <cftransaction> will work the same old fashioned way and there wont
> be any issues.
>
>
> Q1) Your <cfargument>'s type attribute should be matching your table's target
> field's datatype, that is lets assume you have a table named "users" and
> storing the roles in a field called "roles_assigned" which is of integer in
> nature, then you should declare your <cfargument> with the same datatype.
>
>
>
Thanks a lot for that Daverms, I was hoping that 2 or 3 CRUD functions
from a single cfc wrapped in a cftransaction would work just the same as
the old fashioned way.

Regards,
Mark.

[Dan_Bracuk]

quote:

---

What I mean is that I'm trying to follow the latest "trend" of putting
all database queries into a cfc.

---

Adding complexity in the name of fashion? Bad idea.

[Newsgroup_User]

Dan Bracuk wrote:
>

quote:

---

What I mean is that I'm trying to follow the latest "trend" of putting
> all database queries into a cfc.

---

> Adding complexity in the name of fashion? Bad idea.
Hi Dan,

I big part of me wants to agree with you in considering the learning
curve... it's kind of coldfusion, but not as I use to use it... Still,
I'll never be any kind of Guru, but at some levels the who
"encapsulation" thing makes sense on some levels even though there is a
pain of learning in this.. again.

See where you coming from anyway Dan.

Mark.

[Newsgroup_User]

the argument type will be string, since you will be passing a
comma-delimited list.

the transaction will work if you write it correctly. is it going to be a
transaction over several queries in the same cfc function, or spanning
different function calls?


Azadi Saryev
Sabai-dee.com
http://www.sabai-dee.com/

[Newsgroup_User]

Azadi wrote:
> the argument type will be string, since you will be passing a
> comma-delimited list.
>
> the transaction will work if you write it correctly. is it going to be a
> transaction over several queries in the same cfc function, or spanning
> different function calls?
>
>
> Azadi Saryev
> Sabai-dee.com
> http://www.sabai-dee.com/

Hi Azadi,

yes, I want to use the cftransaction wrapped around 2 or 3 different
functions that all reside in a single cfc.... like Daverms suggests, the
functions make up the CRUD, but I want to wrap them in a cftransaction
in some cases.

I hope this clears up my question, it looks like according to Daverms,
the cftransaction will work in this scenario just the same as if the
queries were directly written into the cfm page between the
cftransaction tag, which is the answer I was hoping for :).

thank you for your help,
Mark.

[Dan_Bracuk]

We had a thread in the last week or so where someone posted some of his test results that showed the use of cfc's increased runtime. For me that's another reason to only use them if there is a reason.

The best reason is to make the code available to non cold fusion apps.

The next best reason is to make the code reusable. However, cfc's are not the only way to do this.

There probably are some other reasons, but I've not come across them in my own work.

Any reasons that are purely philosophical are bad reasons.

[Newsgroup_User]

Dan Bracuk wrote:
> We had a thread in the last week or so where someone posted some of his test
> results that showed the use of cfc's increased runtime. For me that's another
> reason to only use them if there is a reason.
>
> The best reason is to make the code available to non cold fusion apps.
>
> The next best reason is to make the code reusable. However, cfc's are not the
> only way to do this.
>
> There probably are some other reasons, but I've not come across them in my own
> work.
>
> Any reasons that are purely philosophical are bad reasons.
>
Hi Dan,

Agreed actually, I may just go back to my good old fashioned way of
doing things... this is at this stage only for my own app anyway, so no
interest in code re-use on this one.

Mark.