Menu
▾
▴
binarycloud-dev — development list for binarycloud
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
(57) |
May
(287) |
Jun
(166) |
Jul
(286) |
Aug
(273) |
Sep
(254) |
Oct
(144) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Odysseas T. <ody...@ya...> - 2001-09-10 21:09:45
|
Its simple, lightweight and I like it a lot. Given PHP's lack of exceptions it can't do what the rest of the *unit variants can but still it's helpful. I have added a little bit of extras to allow browsing/batch execution of all/groups of the test scripts, that we can use too. odysseas --- John Donagher <jo...@we...> wrote: > > You may want to check this out: > http://PhpUnit.sourceforge.net > > That's what odysseas has started using to run tests > here.. > > John > > On Mon, 10 Sep 2001, Alex Black wrote: > > > yeah, I thought about that... > > > > you used anything you like? > > > > _a > > > > > > > > You may want to think about starting a mandatory > unit testing framework before > > > the project gets too far along.. > > > > > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > https://lists.sourceforge.net/lists/listinfo/binarycloud-dev __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com |
|
From: Alex B. <en...@tu...> - 2001-09-10 19:56:18
|
> I use a simple clear image trick that works great when wrestling with tricky > table configurations. I like the idea of manipulating image sizes easily, > but was a little lost in your description there. The idea is to maintain a central 'directory' of all the images used in a particular source tree, so you can for example modify an alt attribute in one place and have that change propagated to _all_ the instances of that image. _a |
|
From: Alex B. <en...@tu...> - 2001-09-10 19:55:15
|
>> On another note, I think it's a great idea to expand the TODO/TASKS >> list. I'm _very_ eager to help with this project, but so much is going >> on all over the place, I haven't found myself comfortable enough >> anywhere to begin. An isolated task list with any/all pertinent >> information would be most helpful. I'm sure I'm not the only developer >> reading this list that feels this way. > > You're exactly right Jason, I want to help too but don't really know where > to pick up. I don't know what different levels of complexity some of the > items involve, and don't know where a beginner php programmer like myself > would be most effective. Any idea on how to fix this? I think you would be most effective building some of the peripheral tools, for example I have spec'd a 'complete' html character entity translation library.. which is a standalone class. Also, there are a number of tasks that need doing like (heh) unit tests, hooking PHPDoc up to make, etc. It depends on what you are interested in doing. -a > Alby |
|
From: Alex B. <en...@tu...> - 2001-09-10 19:53:42
|
> Groovy again. That would be cool. It would also be cool to have a central > resource entity/table that holds text, imagedata, imageurls, urls etc. So we > can dynamically pull out images from database on runtime (i.e. a images > linked to a specific news article). > > Nevertheless we should consider well and take care not exaggerating with > this abstraction stuff. I agree... though I can actually see making these "bc-tags" extensible so they are actually module output that's just put into place at make-time instead of render-time. so you could just make your own tag names and assign them to modules :) -a |
|
From: Andreas A. (Thyrell) <a.a...@th...> - 2001-09-10 19:24:26
|
Hi Alex,
> Is anyone interested in an ImageRequestManager which would use a
> static embed tag like the module embeds:
> <bc:image id="SomeImageID" />
that's groovy.
> I can imagine that being convenient for me...
> would it be convenient for anyone else?
Ohhh most defenetly yes.
> The xml would probably look like:
<!-- binarycloud image repository example file -->
<!--
used in conjunction with:
<bc:image id="SomeImageID" />
-->
<images>
<image>
<!--
This ID is used by the make system. Required.
-->
<id>bcFire</id>
<!--
The image source. We could set a constant called
BC_PATH_IMAGES or something that would allow make
to know that it should prepend that value to all
image paths
-->
<src>resources/images/binarycloud/tmpl/fire.jpg</src>
<!--
The value of the 'name' attribute in the img tag
-->
<name>ImageName</name>
<!--
The alt attribute. Note the language reference
-->
<alt:en>binarycloud fire</alt:en>
<!--
The 'align' attribute in the img tag
-->
<align>left</align>
<hspace>10</hspace>
<vspace>10</vspace>
<!--
If left undefined, this is assumed to be 0
-->
<border>0</border>
<usemap>#moo</usemap>
<!--
only specify these if you want to override the make system's
automatic image-checking features
-->
<width>400</width>
<height>20</height>
</image>
</images>
> Of course the other possibility is to turn this into an Entity, and > run
image makes from the database... hehehe
Groovy again. That would be cool. It would also be cool to have a central
resource entity/table that holds text, imagedata, imageurls, urls etc. So we
can dynamically pull out images from database on runtime (i.e. a images
linked to a specific news article).
Nevertheless we should consider well and take care not exaggerating with
this abstraction stuff.
Andi
|
|
From: Albert L. <a.l...@ve...> - 2001-09-10 19:20:24
|
I use a simple clear image trick that works great when wrestling with tricky table configurations. I like the idea of manipulating image sizes easily, but was a little lost in your description there. Alby > Is anyone interested in an ImageRequestManager which would use a static > embed tag like the module embeds: > > <bc:image id="SomeImageID" /> > > the reason I thought of doing this: > -if people use this 'embed' tag, the make system can use a central image > info repository to build well-formed tags that include alts, the _real_ > width and height of an image, etc. Of course we could allow overrides: > > <bc:image id="SomeImageID" alt="Some Other Alt You want" width="20" /> > > but in general you'd just use the simple tag. > > I can imagine that being convenient for me... would it be convenient for > anyone else? > > The xml would probably look like: > > <!-- binarycloud image repository example file --> > <!-- > used in conjunction with: > <bc:image id="SomeImageID" /> > --> > <images> > <image> > <!-- > This ID is used by the make system. Required. > --> > <id>bcFire</id> > <!-- > The image source. We could set a constant called > BC_PATH_IMAGES or something that would allow make > to know that it should prepend that value to all > image paths > --> > <src>resources/images/binarycloud/tmpl/fire.jpg</src> > <!-- > The value of the 'name' attribute in the img tag > --> > <name>ImageName</name> > <!-- > The alt attribute. Note the language reference > --> > <alt:en>binarycloud fire</alt:en> > <!-- > The 'align' attribute in the img tag > --> > <align>left</align> > > <hspace>10</hspace> > <vspace>10</vspace> > <!-- > If left undefined, this is assumed to be 0 > --> > <border>0</border> > <usemap>#moo</usemap> > <!-- > only specify these if you want to override the make system's > automatic image-checking features > --> > <width>400</width> > <height>20</height> > </image> > </images> > > Of course the other possibility is to turn this into an Entity, and run > image makes from the database... hehehe > > best, > > _alex > |
|
From: Albert L. <a.l...@ve...> - 2001-09-10 19:18:18
|
> On another note, I think it's a great idea to expand the TODO/TASKS > list. I'm _very_ eager to help with this project, but so much is going > on all over the place, I haven't found myself comfortable enough > anywhere to begin. An isolated task list with any/all pertinent > information would be most helpful. I'm sure I'm not the only developer > reading this list that feels this way. You're exactly right Jason, I want to help too but don't really know where to pick up. I don't know what different levels of complexity some of the items involve, and don't know where a beginner php programmer like myself would be most effective. Any idea on how to fix this? Alby |
|
From: Alex B. <en...@tu...> - 2001-09-10 19:15:52
|
yep, it's in CVS. I'll have a look... anyone feel like writing a test case for Page? :) _a > > You may want to check this out: > http://PhpUnit.sourceforge.net > > That's what odysseas has started using to run tests here.. > > John > > On Mon, 10 Sep 2001, Alex Black wrote: > >> yeah, I thought about that... >> >> you used anything you like? >> >> _a >> >>> >>> You may want to think about starting a mandatory unit testing framework >>> before >>> the project gets too far along.. >>> > > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > https://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
|
From: Alex B. <en...@tu...> - 2001-09-10 19:09:23
|
> AIEEEHH.. I though we were steering clear of HTML abstraction. If the No. That's what formbuilder and listbuilder effectively do: abstract html so you can just say "give me a furbees form" instead of writing a bunch of html for every form. > reason to have such a Manager is to ensure all images are properly > tagged, it would make sense to abstract all/most HTML to ensure we meet > XHTML compliance. I disagree, though you're welcome to do that with libs, etc. I have found that in large projects, a central ability to manage images and their properties is useful... thus the bc:image tag thing. Actually there wouldn't be a module or an ImageRequestManager, it would be a function of the make system, like LangKeyer. > This is so far down the line, but still an interesting thought. > jason _a |
|
From: John D. <jo...@we...> - 2001-09-10 19:08:15
|
You may want to check this out: http://PhpUnit.sourceforge.net That's what odysseas has started using to run tests here.. John On Mon, 10 Sep 2001, Alex Black wrote: > yeah, I thought about that... > > you used anything you like? > > _a > > > > > You may want to think about starting a mandatory unit testing framework before > > the project gets too far along.. > > |
|
From: Alex B. <en...@tu...> - 2001-09-10 19:05:44
|
http://PhpUnit.sourceforge.net/ opinions? _a > You may want to think about starting a mandatory unit testing framework before > the project gets too far along.. > > On Sun, 9 Sep 2001, Alex Black wrote: > >> hi all, >> >> I've revised the TODO so it's an index to the tasks/ directory (in cvs >> shortly)... basically there will be a 'task file' for each of the tasks >> listed in the todo, which gives the reader a pretty clear picture of what >> needs to happen. >> >> here's the new TODO: (can anyone see anything that's missing from this?) >> >> best, >> >> -a >> >> ## >> # r2/TODO >> ## >> >> Core >> ------------------------------------------------ >> -PEAR_Error integrated and in wide use >> -All core classes use Request for user-space variables >> -Build Authentication and Permissions >> >> EntityManager & Friends >> ------------------------------------------------ >> -Test QueryManager >> -Re-build EntityManager to handle new Entity Definitions >> Including Validators and Processors >> -Build Tests for the new EntityManager >> -Build TemplateManager >> -Build EventManager >> -Build JSRequestManager >> -Build CSSRequestManager >> -BUild Basic set of Validators and Processors >> >> Make >> ------------------------------------------------ >> -Multi-site make >> (http://www.geocrawler.com/lists/3/SourceForge/9659/0/6177512/) >> -Gif, CSS, Browser-rsrc Standards >> -PHPDoc Integrated >> -Configuration scheme for Make >> -String Keyer & Repositories >> -Static Module Embed Syntax >> -Last Modification Date Check to Speed Makes >> -Recognize FileName.lang_code.php in place of FileName.php >> -Extend XML2PHP to handle Entity Definitions >> -Build ENT2SCHEMA utility which will build metabase XML schemas from Entity >> Definitions >> -Extend ENT2SCHEMA to output SQL >> -Integrate Zend Encoder >> -Integrate Misc Tools (comment stripper, etc) >> >> Builders >> ------------------------------------------------ >> -Get UIControlBuilder Working >> -Build FormBuilder (from existing code) >> -Build ListBuilder (from existing code) >> -Build WizardBuilder (from existing code) >> -PageDefBuilder >> -TreeBuilder (post-r2a release) >> -CalendarBuilder (post-r2a release) >> -EmailBuilder (post-r2a release) >> -FaxBuilder (post-r2a release) >> -PDFBuilder (post-r2a release) >> >> >> Misc >> ------------------------------------------------ >> -Complete, fully functional HTML entity encoding lib >> -Encapsulation scheme for native php templates >> -All files have the current LGPL header. >> -Build golden "reference module" >> >> >> _______________________________________________ >> binarycloud-dev mailing list >> bin...@li... >> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev >> >> |
|
From: Jason H. <jc...@ey...> - 2001-09-10 18:57:42
|
AIEEEHH.. I though we were steering clear of HTML abstraction. If the reason to have such a Manager is to ensure all images are properly tagged, it would make sense to abstract all/most HTML to ensure we meet XHTML compliance. This is so far down the line, but still an interesting thought. jason Alex Black wrote: > Is anyone interested in an ImageRequestManager which would use a static > embed tag like the module embeds: > > <bc:image id="SomeImageID" /> > > the reason I thought of doing this: > -if people use this 'embed' tag, the make system can use a central image > info repository to build well-formed tags that include alts, the _real_ > width and height of an image, etc. Of course we could allow overrides: > > <bc:image id="SomeImageID" alt="Some Other Alt You want" width="20" /> > > but in general you'd just use the simple tag. > > I can imagine that being convenient for me... would it be convenient for > anyone else? > > The xml would probably look like: > > <!-- binarycloud image repository example file --> > <!-- > used in conjunction with: > <bc:image id="SomeImageID" /> > --> > <images> > <image> > <!-- > This ID is used by the make system. Required. > --> > <id>bcFire</id> > <!-- > The image source. We could set a constant called > BC_PATH_IMAGES or something that would allow make > to know that it should prepend that value to all > image paths > --> > <src>resources/images/binarycloud/tmpl/fire.jpg</src> > <!-- > The value of the 'name' attribute in the img tag > --> > <name>ImageName</name> > <!-- > The alt attribute. Note the language reference > --> > <alt:en>binarycloud fire</alt:en> > <!-- > The 'align' attribute in the img tag > --> > <align>left</align> > > <hspace>10</hspace> > <vspace>10</vspace> > <!-- > If left undefined, this is assumed to be 0 > --> > <border>0</border> > <usemap>#moo</usemap> > <!-- > only specify these if you want to override the make system's > automatic image-checking features > --> > <width>400</width> > <height>20</height> > </image> > </images> > > Of course the other possibility is to turn this into an Entity, and run > image makes from the database... hehehe |
|
From: Alex B. <en...@tu...> - 2001-09-10 18:56:40
|
>> I think you'd probably just want to have a flag in the form Definition that >> says "Do JS validation on this one with some stock function" >> >> I'm sure that would be pretty easy to do. > > > I noticed the event flags in the entityDefs (onChange, onBlur, etc). It uh... where? There aren't any Onchange/onblur/ etc flags in entity defs. There may be in UI control definitions. I wanted to associate default UI Controls with each entity field for convenience, but that's the only place On(x) would ever go. > looks like the facility to add client-side validation (minimal) is > pretty much in place. Perhaps this is something that can be messed with > in the future. Yes, pretty much. We can probably do UI Controls for the JS validation pieces or something, such that formBuilder just assembles the outpt from UIControlBuilder. > On another note, I think it's a great idea to expand the TODO/TASKS > list. I'm _very_ eager to help with this project, but so much is going > on all over the place, I haven't found myself comfortable enough > anywhere to begin. An isolated task list with any/all pertinent > information would be most helpful. I'm sure I'm not the only developer > reading this list that feels this way. Yeah, I had that feeling. I've done a portion of the task defs, and will continue to work through them. I'll let everyone know when I'm done. At this point, the tasks can be divided up into two camps: make and EntityManager. I'm much more concerned with EntityManager at the moment, because we can always return to Make and construct new and cool things: but the system isn't complete until that stuff is up and working. After the Make and EM tasks are done, we can get into builders, and the system will be pretty near done. Most of the Builder code already exists, also. :) > SO EVERYONE WAKE UP AND START ASKING QUESTIONS. =] heh _a |
|
From: Alex B. <en...@tu...> - 2001-09-10 18:48:47
|
yeah, I thought about that... you used anything you like? _a > > You may want to think about starting a mandatory unit testing framework before > the project gets too far along.. > > On Sun, 9 Sep 2001, Alex Black wrote: > >> hi all, >> >> I've revised the TODO so it's an index to the tasks/ directory (in cvs >> shortly)... basically there will be a 'task file' for each of the tasks >> listed in the todo, which gives the reader a pretty clear picture of what >> needs to happen. >> >> here's the new TODO: (can anyone see anything that's missing from this?) >> >> best, >> >> -a >> >> ## >> # r2/TODO >> ## >> >> Core >> ------------------------------------------------ >> -PEAR_Error integrated and in wide use >> -All core classes use Request for user-space variables >> -Build Authentication and Permissions >> >> EntityManager & Friends >> ------------------------------------------------ >> -Test QueryManager >> -Re-build EntityManager to handle new Entity Definitions >> Including Validators and Processors >> -Build Tests for the new EntityManager >> -Build TemplateManager >> -Build EventManager >> -Build JSRequestManager >> -Build CSSRequestManager >> -BUild Basic set of Validators and Processors >> >> Make >> ------------------------------------------------ >> -Multi-site make >> (http://www.geocrawler.com/lists/3/SourceForge/9659/0/6177512/) >> -Gif, CSS, Browser-rsrc Standards >> -PHPDoc Integrated >> -Configuration scheme for Make >> -String Keyer & Repositories >> -Static Module Embed Syntax >> -Last Modification Date Check to Speed Makes >> -Recognize FileName.lang_code.php in place of FileName.php >> -Extend XML2PHP to handle Entity Definitions >> -Build ENT2SCHEMA utility which will build metabase XML schemas from Entity >> Definitions >> -Extend ENT2SCHEMA to output SQL >> -Integrate Zend Encoder >> -Integrate Misc Tools (comment stripper, etc) >> >> Builders >> ------------------------------------------------ >> -Get UIControlBuilder Working >> -Build FormBuilder (from existing code) >> -Build ListBuilder (from existing code) >> -Build WizardBuilder (from existing code) >> -PageDefBuilder >> -TreeBuilder (post-r2a release) >> -CalendarBuilder (post-r2a release) >> -EmailBuilder (post-r2a release) >> -FaxBuilder (post-r2a release) >> -PDFBuilder (post-r2a release) >> >> >> Misc >> ------------------------------------------------ >> -Complete, fully functional HTML entity encoding lib >> -Encapsulation scheme for native php templates >> -All files have the current LGPL header. >> -Build golden "reference module" >> >> >> _______________________________________________ >> binarycloud-dev mailing list >> bin...@li... >> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev >> >> |
|
From: Alex B. <en...@tu...> - 2001-09-10 18:48:04
|
> Hi,
>
> Jepp, sounds good. But only for "required-by-core-modules". Other more
> independent but still default suff should go to user/default/mod, I think.
Agreed.
These are modules which should _always_ be static, and required by the
system. I'm thinking things like the module for CSS and JS requests (maybe
images, also...).. etc.
Actually...
Is anyone interested in an ImageRequestManager which would use a static
embed tag like the module embeds:
<bc:image id="SomeImageID" />
the reason I thought of doing this:
-if people use this 'embed' tag, the make system can use a central image
info repository to build well-formed tags that include alts, the _real_
width and height of an image, etc. Of course we could allow overrides:
<bc:image id="SomeImageID" alt="Some Other Alt You want" width="20" />
but in general you'd just use the simple tag.
I can imagine that being convenient for me... would it be convenient for
anyone else?
The xml would probably look like:
<!-- binarycloud image repository example file -->
<!--
used in conjunction with:
<bc:image id="SomeImageID" />
-->
<images>
<image>
<!--
This ID is used by the make system. Required.
-->
<id>bcFire</id>
<!--
The image source. We could set a constant called
BC_PATH_IMAGES or something that would allow make
to know that it should prepend that value to all
image paths
-->
<src>resources/images/binarycloud/tmpl/fire.jpg</src>
<!--
The value of the 'name' attribute in the img tag
-->
<name>ImageName</name>
<!--
The alt attribute. Note the language reference
-->
<alt:en>binarycloud fire</alt:en>
<!--
The 'align' attribute in the img tag
-->
<align>left</align>
<hspace>10</hspace>
<vspace>10</vspace>
<!--
If left undefined, this is assumed to be 0
-->
<border>0</border>
<usemap>#moo</usemap>
<!--
only specify these if you want to override the make system's
automatic image-checking features
-->
<width>400</width>
<height>20</height>
</image>
</images>
Of course the other possibility is to turn this into an Entity, and run
image makes from the database... hehehe
best,
_alex
> Andi
>
>
>
>> makes sense to me... seems like the best place to put "factory"
>> modules.
>
> alex black wrote:
>> what does everyone think about having binarycloud/base/mod/ in the source
>> tree?
>> I'm thinking that we're going to have a set of modules that will be
> required
>> by certain builders and managers ( the JSRequest and CSSRequest Managers
>> come to mind)
>>
>> thoughts?
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
>
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
>
|
|
From: Jason H. <jc...@ey...> - 2001-09-10 18:39:18
|
Alex Black wrote: > EntityManager uses any Processors and Validators on the dataset to determine > if it is O.K. or bad. If it's ok, EntityManager::Add() returns true, and > FormBuilder presents the 'success' page (or however you have configured it) > is presented. . . . > The idea being that FormBuilder will _only_ be in the business of _building > forms_ - Validation, etc will _always_ happen with EntityManager. Drool.. > I think you'd probably just want to have a flag in the form Definition that > says "Do JS validation on this one with some stock function" > > I'm sure that would be pretty easy to do. I noticed the event flags in the entityDefs (onChange, onBlur, etc). It looks like the facility to add client-side validation (minimal) is pretty much in place. Perhaps this is something that can be messed with in the future. On another note, I think it's a great idea to expand the TODO/TASKS list. I'm _very_ eager to help with this project, but so much is going on all over the place, I haven't found myself comfortable enough anywhere to begin. An isolated task list with any/all pertinent information would be most helpful. I'm sure I'm not the only developer reading this list that feels this way. SO EVERYONE WAKE UP AND START ASKING QUESTIONS. =] jason |
|
From: Andreas A. (Thyrell) <a.a...@th...> - 2001-09-10 18:31:49
|
Hi Jason, >errors, I was curious how FormBuilder will handle this. I've always >preferred the client side javascript checks. IE: if First Name is >blank, an alert explaining the error is sent onSubmit, then focus on >invalid field. I think this will be a additional feauture of FormBuilder (generating the js to validate). But you can not trust on that validation. > The more popular way is too simply process the form, >collecting any errors and display them on a page, with a link back to >the form. Alot of times the link back to the form is a mere >javascript:history.back() which tends to lead to a "Data Missing from >POST operation error" requiring a reload. I guess my question is.. >howwill this work? Actually the from will be redisplayed with the missing/faulty fields cleared and a collection of error noctices somwere on the form page. So you don't have to go back (thats a mess and users hate that ;)) You just correct the errors and press submit again. Andi |
|
From: Alex B. <en...@tu...> - 2001-09-10 18:20:54
|
> Just an off the wall question regarding the FormBuilder and validation
> classes.
heh, cool.
> Since there are many ways of validating user input and displaying any
> errors, I was curious how FormBuilder will handle this. I've always
> preferred the client side javascript checks. IE: if First Name is
> blank, an alert explaining the error is sent onSubmit, then focus on
> invalid field. The more popular way is too simply process the form,
> collecting any errors and display them on a page, with a link back to
> the form. Alot of times the link back to the form is a mere
> javascript:history.back() which tends to lead to a "Data Missing from
> POST operation error" requiring a reload. I guess my question is.. how
> will this work?
_binarycloud_ will provide 'server-side' means of processing and validating
incoming data.
So, for example:
user had a form with:
Name, Email, Address, City, State, Zip
They enter some stuff:
Mr. Foo, moo@foo (note the incorrect email), 123 Moo Lane, Berkeley, CA
94710
I don't have any plans for building JS (i.e. client-side) input vaildation,
but I imagine that would actually be fairly easy to build if you already
have the JS, and I'm happy to give you a flag in formbuilder that says
"generate JS validation..
So assume server-side only:
FormBuilder gets the data back (which is knows _nothing_ about) and passes
it directly to EntityManager.
EntityManager uses any Processors and Validators on the dataset to determine
if it is O.K. or bad. If it's ok, EntityManager::Add() returns true, and
FormBuilder presents the 'success' page (or however you have configured it)
is presented.
If EntityManager::Add() returns false, FormBuilder checks the Error stack
(I'm undecided about this one: whether to register global errors in a stack
which FormBuilder checks, or whether to "localize" the errors and keep them
in context) anyway.. FormBuilder takes those errors and sends back the same
form, but with all kinds of stuff in it, maybe:
"Sorry, you are stupid, please have a look at the errors below"
-> Your email address is not valid, please re-enter it.
Name: Mr. Foo
Red-> Email: moo@foo
Address: 123 Moo Lane
City: Berkeley
State: CA
Zip: 94710
...
The idea being that FormBuilder will _only_ be in the business of _building
forms_ - Validation, etc will _always_ happen with EntityManager.
---------
That's how I see it working.
Re: JS:
I think you'd probably just want to have a flag in the form Definition that
says "Do JS validation on this one with some stock function"
I'm sure that would be pretty easy to do.
_a
|
|
From: John D. <jo...@we...> - 2001-09-10 18:17:29
|
You may want to think about starting a mandatory unit testing framework before the project gets too far along.. On Sun, 9 Sep 2001, Alex Black wrote: > hi all, > > I've revised the TODO so it's an index to the tasks/ directory (in cvs > shortly)... basically there will be a 'task file' for each of the tasks > listed in the todo, which gives the reader a pretty clear picture of what > needs to happen. > > here's the new TODO: (can anyone see anything that's missing from this?) > > best, > > -a > > ## > # r2/TODO > ## > > Core > ------------------------------------------------ > -PEAR_Error integrated and in wide use > -All core classes use Request for user-space variables > -Build Authentication and Permissions > > EntityManager & Friends > ------------------------------------------------ > -Test QueryManager > -Re-build EntityManager to handle new Entity Definitions > Including Validators and Processors > -Build Tests for the new EntityManager > -Build TemplateManager > -Build EventManager > -Build JSRequestManager > -Build CSSRequestManager > -BUild Basic set of Validators and Processors > > Make > ------------------------------------------------ > -Multi-site make > (http://www.geocrawler.com/lists/3/SourceForge/9659/0/6177512/) > -Gif, CSS, Browser-rsrc Standards > -PHPDoc Integrated > -Configuration scheme for Make > -String Keyer & Repositories > -Static Module Embed Syntax > -Last Modification Date Check to Speed Makes > -Recognize FileName.lang_code.php in place of FileName.php > -Extend XML2PHP to handle Entity Definitions > -Build ENT2SCHEMA utility which will build metabase XML schemas from Entity > Definitions > -Extend ENT2SCHEMA to output SQL > -Integrate Zend Encoder > -Integrate Misc Tools (comment stripper, etc) > > Builders > ------------------------------------------------ > -Get UIControlBuilder Working > -Build FormBuilder (from existing code) > -Build ListBuilder (from existing code) > -Build WizardBuilder (from existing code) > -PageDefBuilder > -TreeBuilder (post-r2a release) > -CalendarBuilder (post-r2a release) > -EmailBuilder (post-r2a release) > -FaxBuilder (post-r2a release) > -PDFBuilder (post-r2a release) > > > Misc > ------------------------------------------------ > -Complete, fully functional HTML entity encoding lib > -Encapsulation scheme for native php templates > -All files have the current LGPL header. > -Build golden "reference module" > > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > https://lists.sourceforge.net/lists/listinfo/binarycloud-dev > > -- John Donagher Application Engineer, Intacct Corp. Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD |
|
From: Alex B. <en...@tu...> - 2001-09-10 18:01:47
|
No concern, you can do that now. Just run a symlink from build/site_name/en/htdocs/secure to /var/www/html/secure/site_name and build/site_name/en/htdocs/base (or whatever) to /var/www/html/site_name :) _a > Well, here is our company's current SSL virtual host setup. While it's > not perfect, (it's actually cheap), it may need to be considered as a > possible BC configuration concern. > > > Say we host 10 sites on one server, all with their own vhost/docroot. > For SSL, there is a vhost/docroot pointing to > secure.domain.com/site_name. This allows us to secure multiple sites > under one certification. > > So if the site is: > http://www.site_name.com == /var/www/html/site_name > > the secured pages would be located at: > https://secure.companyname.com/site_name == > /var/www/html/secure/site_name > > Told ya it was cheap. :p > > jason > > > > > Alex Black wrote: >> >>> I'll propose a potential concern here. i'm not sure how HTTPS/SSL is >>> handled (site level vs. page level), but if the secure hostname/path >>> differs from the non-secure hostname/path, make may need to know this at >>> build time. >> >> The hostname couldn't be different (it's not the "virtual name" hostname is >> single and unchangeaable...) but paths could definitely change, and that is >> a good point. >> >>> For example: >>> if only the checkout portion of a site is SSL enabled, and it's moved to >>> a seperate docroot to keep visitors from viewing the rest of the site >>> encrypted, one may want just the checkout.php to sit elsewhere >>> >>> >>> http://mysite.com -> /var/www/html/mysite.com/ >>> which has shop.php (categories.php, specials.php, etc etc) >>> https://mysite.com -> /var/www/html/secure/mysite.com/ >>> which only has checkout.php >> >>> >>> This may be a bit too oddball for BC to support. _shrug_ >> >> But now that I think about it, what prevents you from having this tree?: >> >> user/site_name/htdocs/ >> secure/ >> base/ >> >> doing a make 'like normal' and just setting your virtualhosts accordingly? >> >> ... >> >> I'm trying to think of holes in that theory :) >> >> _a >> >> _______________________________________________ >> binarycloud-dev mailing list >> bin...@li... >> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > https://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
|
From: Jason H. <jc...@ey...> - 2001-09-10 17:58:11
|
Just an off the wall question regarding the FormBuilder and validation classes. Since there are many ways of validating user input and displaying any errors, I was curious how FormBuilder will handle this. I've always preferred the client side javascript checks. IE: if First Name is blank, an alert explaining the error is sent onSubmit, then focus on invalid field. The more popular way is too simply process the form, collecting any errors and display them on a page, with a link back to the form. Alot of times the link back to the form is a mere javascript:history.back() which tends to lead to a "Data Missing from POST operation error" requiring a reload. I guess my question is.. how will this work? Thanks. jason |
|
From: Alex B. <en...@tu...> - 2001-09-10 17:48:58
|
hi all, I just did a proper cvs sync, (by that, I mean doing a complete set comparison of the files and pruning the junk from sf)... please do an update :) _alex |
|
From: Andreas A. (Thyrell) <a.a...@th...> - 2001-09-10 17:44:32
|
Hi, Jepp, sounds good. But only for "required-by-core-modules". Other more independent but still default suff should go to user/default/mod, I think. Andi > makes sense to me... seems like the best place to put "factory" > modules. alex black wrote: > what does everyone think about having binarycloud/base/mod/ in the source > tree? > I'm thinking that we're going to have a set of modules that will be required > by certain builders and managers ( the JSRequest and CSSRequest Managers > come to mind) > > thoughts? _______________________________________________ binarycloud-dev mailing list bin...@li... https://lists.sourceforge.net/lists/listinfo/binarycloud-dev |
|
From: Jason H. <jc...@ey...> - 2001-09-10 17:42:15
|
Well, here is our company's current SSL virtual host setup. While it's not perfect, (it's actually cheap), it may need to be considered as a possible BC configuration concern. Say we host 10 sites on one server, all with their own vhost/docroot. For SSL, there is a vhost/docroot pointing to secure.domain.com/site_name. This allows us to secure multiple sites under one certification. So if the site is: http://www.site_name.com == /var/www/html/site_name the secured pages would be located at: https://secure.companyname.com/site_name == /var/www/html/secure/site_name Told ya it was cheap. :p jason Alex Black wrote: > > > I'll propose a potential concern here. i'm not sure how HTTPS/SSL is > > handled (site level vs. page level), but if the secure hostname/path > > differs from the non-secure hostname/path, make may need to know this at > > build time. > > The hostname couldn't be different (it's not the "virtual name" hostname is > single and unchangeaable...) but paths could definitely change, and that is > a good point. > > > For example: > > if only the checkout portion of a site is SSL enabled, and it's moved to > > a seperate docroot to keep visitors from viewing the rest of the site > > encrypted, one may want just the checkout.php to sit elsewhere > > > > > > http://mysite.com -> /var/www/html/mysite.com/ > > which has shop.php (categories.php, specials.php, etc etc) > > https://mysite.com -> /var/www/html/secure/mysite.com/ > > which only has checkout.php > > > > > This may be a bit too oddball for BC to support. _shrug_ > > But now that I think about it, what prevents you from having this tree?: > > user/site_name/htdocs/ > secure/ > base/ > > doing a make 'like normal' and just setting your virtualhosts accordingly? > > ... > > I'm trying to think of holes in that theory :) > > _a > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > https://lists.sourceforge.net/lists/listinfo/binarycloud-dev |
|
From: Alex B. <en...@tu...> - 2001-09-10 17:14:21
|
> I'll propose a potential concern here. i'm not sure how HTTPS/SSL is > handled (site level vs. page level), but if the secure hostname/path > differs from the non-secure hostname/path, make may need to know this at > build time. The hostname couldn't be different (it's not the "virtual name" hostname is single and unchangeaable...) but paths could definitely change, and that is a good point. > For example: > if only the checkout portion of a site is SSL enabled, and it's moved to > a seperate docroot to keep visitors from viewing the rest of the site > encrypted, one may want just the checkout.php to sit elsewhere > > > http://mysite.com -> /var/www/html/mysite.com/ > which has shop.php (categories.php, specials.php, etc etc) > https://mysite.com -> /var/www/html/secure/mysite.com/ > which only has checkout.php > > This may be a bit too oddball for BC to support. _shrug_ But now that I think about it, what prevents you from having this tree?: user/site_name/htdocs/ secure/ base/ doing a make 'like normal' and just setting your virtualhosts accordingly? ... I'm trying to think of holes in that theory :) _a |
5 messages has been excluded from this view by a project administrator.
