On 16 Jan 2015, at 8:32 am, iPhonzie@G <iphonzie@gmail.com> =wrote:---------------------------------------------------------This message is sent to you because you are subscribed tothe mailing listSure, 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 =userCommonly 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 FriesOn =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.To unsubscribe, E-mail to: =div>archives: http://mail.webdna.us/list/talk@webdna.usBug Reporting: support@webdna.us
On 16 Jan 2015, at 8:32 am, iPhonzie@G <iphonzie@gmail.com> =wrote:---------------------------------------------------------This message is sent to you because you are subscribed tothe mailing listSure, 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 =userCommonly 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 FriesOn =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.To unsubscribe, E-mail to: =div>archives: http://mail.webdna.us/list/talk@webdna.usBug Reporting: support@webdna.us
DOWNLOAD WEBDNA NOW!
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...