Re: [WebDNA] maybe silly suggestion? [founditems]

This WebDNA talk-list message is from

2015


It keeps the original formatting.
numero = 111935
interpreted = N
texte = --Apple-Mail=_3ED596F8-5D1D-4CFB-899B-D3608E893F0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian Your suggestion of being able to save search results is easily achieved = if you use the MySQL methods in WebDNA and maybe that could be a path = that Chris could investigate. In the meantime you could mimic the method by putting the search results = into a text variable that could be accessed anywhere and at any time on = the page. Kind regards Stuart Tremain IDFK Web Developments AUSTRALIA webdna@idfk.com.au > On 16 Jan 2015, at 8:32 am, iPhonzie@G wrote: >=20 > Sure, that=E2=80=99s one aspect of it. >=20 > It=E2=80=99s mostly about keeping things modular and reusable, and = keeping to general MVC patterns. For those unclear on the concept: > =E2=80=A2 M =3D Model - generally the database storage, including code = that understands the meanings of the fields and the relationships = between databases > =E2=80=A2 V =3D View - the HTML code that presents your content to the = user > =E2=80=A2 C =3D Controller - the logic that processes and validates = form variables, executes user actions and decides what (not how) needs = to be shown to the user >=20 > Commonly I keep the bulk of my controller code at the top of a page, = the model code in external function libraries that can be reused by many = pages, and the view code at the end of a page. Where it makes sense, I = try to keep view code out of my controller, and control code out of my = view. >=20 > There are reasonably frequent occasions where I=E2=80=99m working on = the View code and I think =E2=80=9Chey, I did this search at the top of = the page, it would be nice not to duplicate efforts=E2=80=9D, but I = would rather not leave dangling open search contexts from my controller = open throughout the page. >=20 > It=E2=80=99s a stylistic choice that can be done with current tools, = but could be done with significantly less code, simpler syntax, and = better performance if I could save search results (the data not the = presentation) with a built-in tag and re-access it later in the page - = or in separate general-use function libraries that don=E2=80=99t need to = be aware of the details of the page being built. >=20 > Also, for clarification, it was the other Brian (Burton - or maybe = I=E2=80=99m the other Brian) who presented the concept originally. = I=E2=80=99ve just been running wild with delusions of grandeur. >=20 > =E2=80=94 Brian Fries >=20 > On January 15, 2015 at 12:38:57 PM, Kenneth Grome = (ken@webdnasolutions.com ) wrote: >=20 >> =46rom what I understand, Brian wants his founditems contexts to=20 >> work outside his search context, but because this is not the way=20 >> WebDNA works he wants new tags/contexts to implement it.=20 >>=20 >> Is this correct Brian?=20 >>=20 >> Regards,=20 >> Kenneth Grome=20 >> WebDNA Solutions=20 >> http://www.webdnasolutions.com=20 >> Web Database Systems and Linux Server Management=20 >>=20 >>=20 >> On 01/15/2015 02:20 PM, Dan Strong wrote:=20 >> > Gotta admit that I agree with Ken and have from the start. I am=20 >> > not seeing the value of this either, but maybe I just don't "get=20 >> > it" either.=20 >> >=20 >> > Also looking forward to a concrete use case/example to help me=20 >> > understand the concept a bit better.=20 >> >=20 >> > -Dan Strong=20 >> > http://DanStrong.com=20 >> >=20 >> > On Thu, Jan 15, 2015 at 12:10 PM, Kenneth Grome=20 >> > > wrote:=20= >> >=20 >> > > [listfounditems] would have access to all the fields in the=20 >> > > database that was searched=20 >> >=20 >> > Are you suggesting that [listfounditems] cache the results of the=20= >> > original search? If so, this means that each time the page is=20 >> > requested WebDNA must cache a new copy of the founditems data,=20 >> > correct?=20 >> >=20 >> > And how this data going to be formatted? OR is this new context=20 >> > there simply to allow you to use [fieldname] tags -- which we can=20= >> > already do in our [founditems] contexts?=20 >> >=20 >> >=20 >> >=20 >> > > You could reuse the found item set multiple times in you page=20 >> > > without the expensive search.=20 >> >=20 >> > I'm not sure why do you use the term "expensive" here ...=20 >> >=20 >> > If you're currently using more than one identical search per page=20= >> > you're not doing it very efficiently. The better way is to do one=20= >> > search and then use several founditems contexts within that one=20 >> > search context.=20 >> >=20 >> > I do this all the time. I put several founditems context inside=20 >> > my search, then I format the results of each founditems the way I=20= >> > need it to be displayed further on down the page. Then I save the=20= >> > formatted results of each founditems as a text variable, which=20 >> > means I can display the entire formatted results with a simple=20 >> > text tag like [results1].=20 >> >=20 >> > This means I'm doing only one search on the page -- and one search=20= >> > is certainly not "expensive" from my perspective.=20 >> >=20 >> >=20 >> > > You could have multiple found item sets for the same database=20 >> > > without the potential confusion caused by nested searches=20 >> >=20 >> > I almost never do nested searches anyways since there are better=20 >> > ways most of the time.=20 >> >=20 >> >=20 >> > > The search code would not need to know anything about what the=20 >> > > display code will be doing with the results=20 >> >=20 >> > This is nothing different that what we already have with=20 >> > [founditems], is it? If so, how is it different?=20 >> >=20 >> >=20 >> > > Built into the WebDNA engine, this could be much more efficient=20= >> > > than creating a set of functions to implement similar features=20 >> >=20 >> > Yet if we do not need these capabilities -- because we already=20 >> > have them -- we do not need to use functions, and we do not need=20 >> > to further complicate the engine code either, correct?=20 >> >=20 >> >=20 >> > > In my mind, features should be added to WebDNA if and only if = they=20 >> > > add value that cannot be easily and efficiently implemented using=20= >> > > functions. I think this qualifies.=20 >> >=20 >> > Sorry, I still disagree. I have yet to see anything you've=20 >> > described or shown me that I cannot do right now with [founditems]=20= >> > and [text].=20 >> >=20 >> > I'm not trying to be difficult but I truly see no advantage in any=20= >> > of this.=20 >> >=20 >> > Can you show me a concrete example where using multiple founditems=20= >> > and text vars won't do everything you're suggesting? Because so=20 >> > far I still don't get it.=20 >> >=20 >> > Regards,=20 >> > Kenneth Grome=20 >> > WebDNA Solutions=20 >> > http://www.webdnasolutions.com=20 >> > Web Database Systems and Linux Server Management=20 >> >=20 >> >=20 >> > ---------------------------------------------------------=20 >> > This message is sent to you because you are subscribed to=20 >> > the mailing list >.=20 >> > To unsubscribe, E-mail to: > > >=20 >> > archives: http://mail.webdna.us/list/talk@webdna.us=20 >> > Bug Reporting: support@webdna.us =20 >> >=20 >> >=20 >> > --------------------------------------------------------- This=20 >> > message is sent to you because you are subscribed to the mailing=20 >> > list . To unsubscribe, E-mail to: archives:=20 >> > http://mail.webdna.us/list/talk@webdna.us Bug Reporting:=20 >> > support@webdna.us=20 >> ---------------------------------------------------------=20 >> This message is sent to you because you are subscribed to=20 >> the mailing list .=20 >> To unsubscribe, E-mail to: =20 >> archives: http://mail.webdna.us/list/talk@webdna.us=20 >> Bug Reporting: support@webdna.us=20 > --------------------------------------------------------- This message = is sent to you because you are subscribed to the mailing list . To = unsubscribe, E-mail to: archives: = http://mail.webdna.us/list/talk@webdna.us Bug Reporting: = support@webdna.us --Apple-Mail=_3ED596F8-5D1D-4CFB-899B-D3608E893F0F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Brian

Your = suggestion of being able to save search results is easily achieved if = you use the MySQL methods in WebDNA and maybe that could be a path that = Chris could investigate.

In the meantime you could mimic the method by putting the = search results into a text variable that could be accessed anywhere and = at any time on the page.


Kind regards

Stuart Tremain
IDFK Web Developments
AUSTRALIA





On 16 Jan 2015, at 8:32 am, iPhonzie@G <iphonzie@gmail.com> = wrote:

body{font-family:Helvetica,Arial;font-size:13px}
Sure, that=E2=80=99s one = aspect of it.

It=E2=80=99s = mostly about keeping things modular and reusable, and keeping to general = MVC patterns. For those unclear on the concept:
=E2=80=A2 M =3D Model - = generally the database storage, including code that understands the = meanings of the fields and the relationships between databases
=E2=80=A2 V =3D View - the = HTML code that presents your content to the user
=E2=80=A2 C =3D Controller - = the logic that processes and validates form variables, executes user = actions and decides what (not how) needs to be shown to the = user

Commonly I keep the bulk of my = controller code at the top of a page, the model code in external = function libraries that can be reused by many pages, and the view code = at the end of a page. Where it makes sense, I try to keep view code out = of my controller, and control code out of my view.

There are reasonably frequent = occasions where I=E2=80=99m working on the View code and I think =E2=80=9C= hey, I did this search at the top of the page, it would be nice not to = duplicate efforts=E2=80=9D, but I would rather not leave dangling open = search contexts from my controller open throughout the page.

It=E2=80=99s a stylistic = choice that can be done with current tools, but could be done with = significantly less code, simpler syntax, and better performance if I = could save search results (the data not the presentation) with a = built-in tag and re-access it later in the page - or in separate = general-use function libraries that don=E2=80=99t need to be aware of = the details of the page being built.

Also, for clarification, it was the other Brian (Burton - or = maybe I=E2=80=99m the other Brian) who presented the concept originally. = I=E2=80=99ve just been running wild with delusions of = grandeur.

=E2=80=94 = Brian Fries

On = January 15, 2015 at 12:38:57 PM, Kenneth Grome (ken@webdnasolutions.com) wrote:

=46rom what I understand, Brian wants = his founditems contexts to
work outside his search context, but because this is not = the way
WebDNA works he wants new tags/contexts to implement it.

Is this correct Brian?

Regards,
Kenneth Grome
WebDNA Solutions
http://www.webdnasolutions.com
Web Database Systems and Linux Server Management


On 01/15/2015 02:20 PM, Dan Strong wrote:
> Gotta admit that I agree with Ken and have from the = start. I am
> not seeing the value of this either, but maybe I = just don't "get
> it" either. =20
> =20
> Also looking forward to a concrete use case/example = to help me
> understand the concept a bit better.
> =20
> -Dan Strong
> http://DanStrong.com
> =20
> On Thu, Jan 15, 2015 at 12:10 PM, Kenneth Grome
> <ken@webdnasolutions.com <mailto:ken@webdnasolutions.com>> wrote:
> =20
> > [listfounditems] would have access to all = the fields in the
> > database that was searched
> =20
> Are you suggesting that [listfounditems] cache = the results of the
> original search? If so, this means that each = time the page is
> requested WebDNA must cache a new copy of the = founditems data,
> correct?
> =20
> And how this data going to be formatted? OR is = this new context
> there simply to allow you to use [fieldname] = tags -- which we can
> already do in our [founditems] contexts?
> =20
> =20
> =20
> > You could reuse the found item set multiple = times in you page
> > without the expensive search.
> =20
> I'm not sure why do you use the term "expensive" = here ...
> =20
> If you're currently using more than one = identical search per page
> you're not doing it very efficiently. The = better way is to do one
> search and then use several founditems contexts = within that one
> search context.
> =20
> I do this all the time. I put several = founditems context inside
> my search, then I format the results of each = founditems the way I
> need it to be displayed further on down the = page. Then I save the
> formatted results of each founditems as a text = variable, which
> means I can display the entire formatted results = with a simple
> text tag like [results1].
> =20
> This means I'm doing only one search on the page = -- and one search
> is certainly not "expensive" from my = perspective.
> =20
> =20
> > You could have multiple found item sets for = the same database
> > without the potential confusion caused by = nested searches
> =20
> I almost never do nested searches anyways since = there are better
> ways most of the time.
> =20
> =20
> > The search code would not need to know = anything about what the
> > display code will be doing with the results
> =20
> This is nothing different that what we already = have with
> [founditems], is it? If so, how is it = different?
> =20
> =20
> > Built into the WebDNA engine, this could be = much more efficient
> > than creating a set of functions to = implement similar features
> =20
> Yet if we do not need these capabilities -- = because we already
> have them -- we do not need to use functions, = and we do not need
> to further complicate the engine code either, = correct?
> =20
> =20
> > In my mind, features should be added to = WebDNA if and only if they
> > add value that cannot be easily and = efficiently implemented using
> > functions. I think this qualifies.
> =20
> Sorry, I still disagree. I have yet to see = anything you've
> described or shown me that I cannot do right now = with [founditems]
> and [text].
> =20
> I'm not trying to be difficult but I truly see = no advantage in any
> of this.
> =20
> Can you show me a concrete example where using = multiple founditems
> and text vars won't do everything you're = suggesting? Because so
> far I still don't get it.
> =20
> Regards,
> Kenneth Grome
> WebDNA Solutions
> http://www.webdnasolutions.com
> Web Database Systems and Linux Server Management
> =20
> =20
> = ---------------------------------------------------------
> This message is sent to you because you are = subscribed to
> the mailing list <talk@webdna.us <mailto:talk@webdna.us>>.
> To unsubscribe, E-mail to: <talk-leave@webdna.us
> <mailto:talk-leave@webdna.us>>
> archives: http://mail.webdna.us/list/talk@webdna.us
> Bug Reporting: support@webdna.us = <mailto:support@webdna.us>
> =20
> =20
> = --------------------------------------------------------- This
> message is sent to you because you are subscribed to = the mailing
> list . To unsubscribe, E-mail to: archives:
> http://mail.webdna.us/list/talk@webdna.us Bug Reporting:
> support@webdna.us
---------------------------------------------------------
This message is sent to you because you are subscribed to
the mailing list <talk@webdna.us>.
To unsubscribe, E-mail to: <talk-leave@webdna.us>
archives: http://mail.webdna.us/list/talk@webdna.us
Bug Reporting: support@webdna.us
--------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: archives: http://mail.webdna.us/list/talk@webdna.us Bug Reporting: support@webdna.us

= --Apple-Mail=_3ED596F8-5D1D-4CFB-899B-D3608E893F0F-- Associated Messages, from the most recent to the oldest:

    
  1. Re: [WebDNA] maybe silly suggestion? [founditems] (Kenneth Grome 2015)
  2. Re: [WebDNA] maybe silly suggestion? [founditems] (christophe.billiottet@webdna.us 2015)
  3. Re: [WebDNA] maybe silly suggestion? [founditems] (Michael Davis 2015)
  4. Re: [WebDNA] maybe silly suggestion? [founditems] (Kenneth Grome 2015)
  5. Re: [WebDNA] maybe silly suggestion? [founditems] (christophe.billiottet@webdna.us 2015)
  6. Re: [WebDNA] maybe silly suggestion? [founditems] (Stuart Tremain 2015)
  7. Re: [WebDNA] maybe silly suggestion? [founditems] (Dan Strong 2015)
  8. Re: [WebDNA] maybe silly suggestion? [founditems] (Brian Burton 2015)
  9. Re: [WebDNA] maybe silly suggestion? [founditems] (Brian Burton 2015)
  10. Re: [WebDNA] maybe silly suggestion? [founditems] (Dan Strong 2015)
  11. Re: [WebDNA] maybe silly suggestion? [founditems] (Brian Burton 2015)
  12. Re: [WebDNA] maybe silly suggestion? [founditems] (=?utf-8?Q?iPhonzie=40G?= 2015)
  13. Re: [WebDNA] maybe silly suggestion? [founditems] (Brian Burton 2015)
  14. Re: [WebDNA] maybe silly suggestion? [founditems] (Donovan Brooke 2015)
  15. Re: [WebDNA] maybe silly suggestion? [founditems] (Kenneth Grome 2015)
  16. Re: [WebDNA] maybe silly suggestion? [founditems] (Dan Strong 2015)
  17. Re: [WebDNA] maybe silly suggestion? [founditems] (Kenneth Grome 2015)
  18. Re: [WebDNA] maybe silly suggestion? [founditems] (Donovan Brooke 2015)
  19. Re: [WebDNA] maybe silly suggestion? [founditems] (=?utf-8?Q?iPhonzie=40G?= 2015)
  20. Re: [WebDNA] maybe silly suggestion? [founditems] (=?utf-8?Q?iPhonzie=40G?= 2015)
  21. Re: [WebDNA] maybe silly suggestion? [founditems] (christophe.billiottet@webdna.us 2015)
  22. Re: [WebDNA] maybe silly suggestion? [founditems] (Kenneth Grome 2015)
  23. Re: [WebDNA] maybe silly suggestion? [founditems] (=?utf-8?Q?iPhonzie=40G?= 2015)
  24. Re: [WebDNA] maybe silly suggestion? [founditems] (=?utf-8?Q?iPhonzie=40G?= 2015)
  25. Re: [WebDNA] maybe silly suggestion? [founditems] (Stephen Reiss 2015)
  26. Re: [WebDNA] maybe silly suggestion? [founditems] (Terry Wilson 2015)
  27. Re: [WebDNA] maybe silly suggestion? [founditems] (Terry Wilson 2015)
  28. Re: [WebDNA] maybe silly suggestion? [founditems] (Lawrence Banahan 2015)
  29. Re: [WebDNA] maybe silly suggestion? [founditems] ("Psi Prime Inc, Matthew A Perosi " 2015)
  30. Re: [WebDNA] maybe silly suggestion? [founditems] (Donovan Brooke 2015)
  31. Re: [WebDNA] maybe silly suggestion? [founditems] (Donovan Brooke 2015)
  32. Re: [WebDNA] maybe silly suggestion? [founditems] (Kenneth Grome 2015)
  33. Re: [WebDNA] maybe silly suggestion? [founditems] (Terry Wilson 2015)
  34. Re: [WebDNA] maybe silly suggestion? [founditems] (Donovan Brooke 2015)
  35. Re: [WebDNA] maybe silly suggestion? [founditems] (Donovan Brooke 2015)
  36. Re: [WebDNA] maybe silly suggestion? [founditems] (Terry Wilson 2015)
  37. Re: [WebDNA] maybe silly suggestion? [founditems] (Kenneth Grome 2015)
  38. Re: [WebDNA] maybe silly suggestion? [founditems] (Donovan Brooke 2015)
  39. Re: [WebDNA] maybe silly suggestion? [founditems] (Donovan Brooke 2015)
  40. Re: [WebDNA] maybe silly suggestion? [founditems] (christophe.billiottet@webdna.us 2015)
  41. Re: [WebDNA] maybe silly suggestion? [founditems] (Kenneth Grome 2015)
  42. [WebDNA] maybe silly suggestion? [founditems] (Brian Burton 2015)
--Apple-Mail=_3ED596F8-5D1D-4CFB-899B-D3608E893F0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian Your suggestion of being able to save search results is easily achieved = if you use the MySQL methods in WebDNA and maybe that could be a path = that Chris could investigate. In the meantime you could mimic the method by putting the search results = into a text variable that could be accessed anywhere and at any time on = the page. Kind regards Stuart Tremain IDFK Web Developments AUSTRALIA webdna@idfk.com.au > On 16 Jan 2015, at 8:32 am, iPhonzie@G wrote: >=20 > Sure, that=E2=80=99s one aspect of it. >=20 > It=E2=80=99s mostly about keeping things modular and reusable, and = keeping to general MVC patterns. For those unclear on the concept: > =E2=80=A2 M =3D Model - generally the database storage, including code = that understands the meanings of the fields and the relationships = between databases > =E2=80=A2 V =3D View - the HTML code that presents your content to the = user > =E2=80=A2 C =3D Controller - the logic that processes and validates = form variables, executes user actions and decides what (not how) needs = to be shown to the user >=20 > Commonly I keep the bulk of my controller code at the top of a page, = the model code in external function libraries that can be reused by many = pages, and the view code at the end of a page. Where it makes sense, I = try to keep view code out of my controller, and control code out of my = view. >=20 > There are reasonably frequent occasions where I=E2=80=99m working on = the View code and I think =E2=80=9Chey, I did this search at the top of = the page, it would be nice not to duplicate efforts=E2=80=9D, but I = would rather not leave dangling open search contexts from my controller = open throughout the page. >=20 > It=E2=80=99s a stylistic choice that can be done with current tools, = but could be done with significantly less code, simpler syntax, and = better performance if I could save search results (the data not the = presentation) with a built-in tag and re-access it later in the page - = or in separate general-use function libraries that don=E2=80=99t need to = be aware of the details of the page being built. >=20 > Also, for clarification, it was the other Brian (Burton - or maybe = I=E2=80=99m the other Brian) who presented the concept originally. = I=E2=80=99ve just been running wild with delusions of grandeur. >=20 > =E2=80=94 Brian Fries >=20 > On January 15, 2015 at 12:38:57 PM, Kenneth Grome = (ken@webdnasolutions.com ) wrote: >=20 >> =46rom what I understand, Brian wants his founditems contexts to=20 >> work outside his search context, but because this is not the way=20 >> WebDNA works he wants new tags/contexts to implement it.=20 >>=20 >> Is this correct Brian?=20 >>=20 >> Regards,=20 >> Kenneth Grome=20 >> WebDNA Solutions=20 >> http://www.webdnasolutions.com=20 >> Web Database Systems and Linux Server Management=20 >>=20 >>=20 >> On 01/15/2015 02:20 PM, Dan Strong wrote:=20 >> > Gotta admit that I agree with Ken and have from the start. I am=20 >> > not seeing the value of this either, but maybe I just don't "get=20 >> > it" either.=20 >> >=20 >> > Also looking forward to a concrete use case/example to help me=20 >> > understand the concept a bit better.=20 >> >=20 >> > -Dan Strong=20 >> > http://DanStrong.com=20 >> >=20 >> > On Thu, Jan 15, 2015 at 12:10 PM, Kenneth Grome=20 >> > > wrote:=20= >> >=20 >> > > [listfounditems] would have access to all the fields in the=20 >> > > database that was searched=20 >> >=20 >> > Are you suggesting that [listfounditems] cache the results of the=20= >> > original search? If so, this means that each time the page is=20 >> > requested WebDNA must cache a new copy of the founditems data,=20 >> > correct?=20 >> >=20 >> > And how this data going to be formatted? OR is this new context=20 >> > there simply to allow you to use [fieldname] tags -- which we can=20= >> > already do in our [founditems] contexts?=20 >> >=20 >> >=20 >> >=20 >> > > You could reuse the found item set multiple times in you page=20 >> > > without the expensive search.=20 >> >=20 >> > I'm not sure why do you use the term "expensive" here ...=20 >> >=20 >> > If you're currently using more than one identical search per page=20= >> > you're not doing it very efficiently. The better way is to do one=20= >> > search and then use several founditems contexts within that one=20 >> > search context.=20 >> >=20 >> > I do this all the time. I put several founditems context inside=20 >> > my search, then I format the results of each founditems the way I=20= >> > need it to be displayed further on down the page. Then I save the=20= >> > formatted results of each founditems as a text variable, which=20 >> > means I can display the entire formatted results with a simple=20 >> > text tag like [results1].=20 >> >=20 >> > This means I'm doing only one search on the page -- and one search=20= >> > is certainly not "expensive" from my perspective.=20 >> >=20 >> >=20 >> > > You could have multiple found item sets for the same database=20 >> > > without the potential confusion caused by nested searches=20 >> >=20 >> > I almost never do nested searches anyways since there are better=20 >> > ways most of the time.=20 >> >=20 >> >=20 >> > > The search code would not need to know anything about what the=20 >> > > display code will be doing with the results=20 >> >=20 >> > This is nothing different that what we already have with=20 >> > [founditems], is it? If so, how is it different?=20 >> >=20 >> >=20 >> > > Built into the WebDNA engine, this could be much more efficient=20= >> > > than creating a set of functions to implement similar features=20 >> >=20 >> > Yet if we do not need these capabilities -- because we already=20 >> > have them -- we do not need to use functions, and we do not need=20 >> > to further complicate the engine code either, correct?=20 >> >=20 >> >=20 >> > > In my mind, features should be added to WebDNA if and only if = they=20 >> > > add value that cannot be easily and efficiently implemented using=20= >> > > functions. I think this qualifies.=20 >> >=20 >> > Sorry, I still disagree. I have yet to see anything you've=20 >> > described or shown me that I cannot do right now with [founditems]=20= >> > and [text].=20 >> >=20 >> > I'm not trying to be difficult but I truly see no advantage in any=20= >> > of this.=20 >> >=20 >> > Can you show me a concrete example where using multiple founditems=20= >> > and text vars won't do everything you're suggesting? Because so=20 >> > far I still don't get it.=20 >> >=20 >> > Regards,=20 >> > Kenneth Grome=20 >> > WebDNA Solutions=20 >> > http://www.webdnasolutions.com=20 >> > Web Database Systems and Linux Server Management=20 >> >=20 >> >=20 >> > ---------------------------------------------------------=20 >> > This message is sent to you because you are subscribed to=20 >> > the mailing list >.=20 >> > To unsubscribe, E-mail to: > > >=20 >> > archives: http://mail.webdna.us/list/talk@webdna.us=20 >> > Bug Reporting: support@webdna.us =20 >> >=20 >> >=20 >> > --------------------------------------------------------- This=20 >> > message is sent to you because you are subscribed to the mailing=20 >> > list . To unsubscribe, E-mail to: archives:=20 >> > http://mail.webdna.us/list/talk@webdna.us Bug Reporting:=20 >> > support@webdna.us=20 >> ---------------------------------------------------------=20 >> This message is sent to you because you are subscribed to=20 >> the mailing list .=20 >> To unsubscribe, E-mail to: =20 >> archives: http://mail.webdna.us/list/talk@webdna.us=20 >> Bug Reporting: support@webdna.us=20 > --------------------------------------------------------- This message = is sent to you because you are subscribed to the mailing list . To = unsubscribe, E-mail to: archives: = http://mail.webdna.us/list/talk@webdna.us Bug Reporting: = support@webdna.us --Apple-Mail=_3ED596F8-5D1D-4CFB-899B-D3608E893F0F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Brian

Your = suggestion of being able to save search results is easily achieved if = you use the MySQL methods in WebDNA and maybe that could be a path that = Chris could investigate.

In the meantime you could mimic the method by putting the = search results into a text variable that could be accessed anywhere and = at any time on the page.


Kind regards

Stuart Tremain
IDFK Web Developments
AUSTRALIA





On 16 Jan 2015, at 8:32 am, iPhonzie@G <iphonzie@gmail.com> = wrote:

body{font-family:Helvetica,Arial;font-size:13px}
Sure, that=E2=80=99s one = aspect of it.

It=E2=80=99s = mostly about keeping things modular and reusable, and keeping to general = MVC patterns. For those unclear on the concept:
=E2=80=A2 M =3D Model - = generally the database storage, including code that understands the = meanings of the fields and the relationships between databases
=E2=80=A2 V =3D View - the = HTML code that presents your content to the user
=E2=80=A2 C =3D Controller - = the logic that processes and validates form variables, executes user = actions and decides what (not how) needs to be shown to the = user

Commonly I keep the bulk of my = controller code at the top of a page, the model code in external = function libraries that can be reused by many pages, and the view code = at the end of a page. Where it makes sense, I try to keep view code out = of my controller, and control code out of my view.

There are reasonably frequent = occasions where I=E2=80=99m working on the View code and I think =E2=80=9C= hey, I did this search at the top of the page, it would be nice not to = duplicate efforts=E2=80=9D, but I would rather not leave dangling open = search contexts from my controller open throughout the page.

It=E2=80=99s a stylistic = choice that can be done with current tools, but could be done with = significantly less code, simpler syntax, and better performance if I = could save search results (the data not the presentation) with a = built-in tag and re-access it later in the page - or in separate = general-use function libraries that don=E2=80=99t need to be aware of = the details of the page being built.

Also, for clarification, it was the other Brian (Burton - or = maybe I=E2=80=99m the other Brian) who presented the concept originally. = I=E2=80=99ve just been running wild with delusions of = grandeur.

=E2=80=94 = Brian Fries

On = January 15, 2015 at 12:38:57 PM, Kenneth Grome (ken@webdnasolutions.com) wrote:

=46rom what I understand, Brian wants = his founditems contexts to
work outside his search context, but because this is not = the way
WebDNA works he wants new tags/contexts to implement it.

Is this correct Brian?

Regards,
Kenneth Grome
WebDNA Solutions
http://www.webdnasolutions.com
Web Database Systems and Linux Server Management


On 01/15/2015 02:20 PM, Dan Strong wrote:
> Gotta admit that I agree with Ken and have from the = start. I am
> not seeing the value of this either, but maybe I = just don't "get
> it" either. =20
> =20
> Also looking forward to a concrete use case/example = to help me
> understand the concept a bit better.
> =20
> -Dan Strong
> http://DanStrong.com
> =20
> On Thu, Jan 15, 2015 at 12:10 PM, Kenneth Grome
> <ken@webdnasolutions.com <mailto:ken@webdnasolutions.com>> wrote:
> =20
> > [listfounditems] would have access to all = the fields in the
> > database that was searched
> =20
> Are you suggesting that [listfounditems] cache = the results of the
> original search? If so, this means that each = time the page is
> requested WebDNA must cache a new copy of the = founditems data,
> correct?
> =20
> And how this data going to be formatted? OR is = this new context
> there simply to allow you to use [fieldname] = tags -- which we can
> already do in our [founditems] contexts?
> =20
> =20
> =20
> > You could reuse the found item set multiple = times in you page
> > without the expensive search.
> =20
> I'm not sure why do you use the term "expensive" = here ...
> =20
> If you're currently using more than one = identical search per page
> you're not doing it very efficiently. The = better way is to do one
> search and then use several founditems contexts = within that one
> search context.
> =20
> I do this all the time. I put several = founditems context inside
> my search, then I format the results of each = founditems the way I
> need it to be displayed further on down the = page. Then I save the
> formatted results of each founditems as a text = variable, which
> means I can display the entire formatted results = with a simple
> text tag like [results1].
> =20
> This means I'm doing only one search on the page = -- and one search
> is certainly not "expensive" from my = perspective.
> =20
> =20
> > You could have multiple found item sets for = the same database
> > without the potential confusion caused by = nested searches
> =20
> I almost never do nested searches anyways since = there are better
> ways most of the time.
> =20
> =20
> > The search code would not need to know = anything about what the
> > display code will be doing with the results
> =20
> This is nothing different that what we already = have with
> [founditems], is it? If so, how is it = different?
> =20
> =20
> > Built into the WebDNA engine, this could be = much more efficient
> > than creating a set of functions to = implement similar features
> =20
> Yet if we do not need these capabilities -- = because we already
> have them -- we do not need to use functions, = and we do not need
> to further complicate the engine code either, = correct?
> =20
> =20
> > In my mind, features should be added to = WebDNA if and only if they
> > add value that cannot be easily and = efficiently implemented using
> > functions. I think this qualifies.
> =20
> Sorry, I still disagree. I have yet to see = anything you've
> described or shown me that I cannot do right now = with [founditems]
> and [text].
> =20
> I'm not trying to be difficult but I truly see = no advantage in any
> of this.
> =20
> Can you show me a concrete example where using = multiple founditems
> and text vars won't do everything you're = suggesting? Because so
> far I still don't get it.
> =20
> Regards,
> Kenneth Grome
> WebDNA Solutions
> http://www.webdnasolutions.com
> Web Database Systems and Linux Server Management
> =20
> =20
> = ---------------------------------------------------------
> This message is sent to you because you are = subscribed to
> the mailing list <talk@webdna.us <mailto:talk@webdna.us>>.
> To unsubscribe, E-mail to: <talk-leave@webdna.us
> <mailto:talk-leave@webdna.us>>
> archives: http://mail.webdna.us/list/talk@webdna.us
> Bug Reporting: support@webdna.us = <mailto:support@webdna.us>
> =20
> =20
> = --------------------------------------------------------- This
> message is sent to you because you are subscribed to = the mailing
> list . To unsubscribe, E-mail to: archives:
> http://mail.webdna.us/list/talk@webdna.us Bug Reporting:
> support@webdna.us
---------------------------------------------------------
This message is sent to you because you are subscribed to
the mailing list <talk@webdna.us>.
To unsubscribe, E-mail to: <talk-leave@webdna.us>
archives: http://mail.webdna.us/list/talk@webdna.us
Bug Reporting: support@webdna.us
--------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: archives: http://mail.webdna.us/list/talk@webdna.us Bug Reporting: support@webdna.us

= --Apple-Mail=_3ED596F8-5D1D-4CFB-899B-D3608E893F0F-- Stuart Tremain

DOWNLOAD WEBDNA NOW!

Top Articles:

Talk List

The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...

Related Readings:

RE: [WebDNA] [OT] Need to add second SSL host - what are my options? (2010) Bad card db - *mislabled post* (1999) FW: Runtime version ... (2003) Authorize.net, SIM, tcpconnect and applescript (2003) unsubscribe (1997) Tab Delimited Files / FM Pro (1997) Uploading out of FMP (2001) help needed: Non-english characters in WebCatalog (1997) MetaKW tags from databases (2006) File Uploads: WebCat/SiteEdit (1998) Re:HELP - NONE STOP DIGESTS. Digest for 4/24/97) (1997) writefiles (1999) Grep Question - MAY NEVER BE SOLVED (2003) Mac: LModelDirector bug fix (1997) problems with 2 tags (1997) TCP/IP connect (1998) Setting up shop (1997) Is [thisurl] http or https? (1998) WebCat for News Gathering (1999) no global [username] or [password] displayed ... (1997)