Menu
▾
▴
websyntax-users — For developers using the Syntax framework and toolkit
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(5) |
Apr
(4) |
May
(6) |
Jun
(2) |
Jul
(3) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ben...@id...> - 2004-05-22 13:07:43
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Sandy S. <ss...@fo...> - 2003-08-14 16:04:14
|
Choose Relationship only shows relationships on those objects it is
defined for. It is also directional, and will only appear from the
datatype on the right-hand side (datatype1). This is somewhat
misleading behavior, as the relationships as recorded in primaryrel are
in fact bidirectional. The workaround is to define them both
simultaneously (click both datatypes in both the right- and left-hand
columns when you are creating it).
However, there is a known bug if you edit a relationship after creating
it. The title disappears for some reason we haven't yet been able to
track down, and the field becomes blank.
The (admittedly ugly) work around at this point is to shell in and
replace the title in the relationships table for that relationship from
the command line. (UPDATE relationships SET description='Relationship
title' WHERE id = {ID of the relationship})
Work has been fairly busy and internal development needs have focused
elsewhere, so I can't give you an ETA on that bugfix. The workrounds do
work, however.
Thanks,
Sandy
On Thursday, August 14, 2003, at 10:28 AM, Adrian Columb wrote:
> Hi all,
>
> When I try to create a new relationship field in a datatype in the
> Object
> section of DBasis, the 'Choose Relationship' menu is empty - how can
> this
> menu be made to show the relationships defined in the Relationships
> section?
>
> Kind regards,
>
> Adrian
> ___
> Adrian Columb
> Communication Consultant, CBDagency
> http://www.CBDagency.com/
> Communication - Branding - Design
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/
> direct;at.aspnet_072303_01/01
> _______________________________________________
> Websyntax-users mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/websyntax-users
>
>
--
Sandy Smith, Senior Programmer
Forum One Communications, Inc.
ss...@fo...
tel. 703-548-1855 x28
http://www.forumone.com/
|
|
From: Adrian C. <ad...@cb...> - 2003-08-14 14:32:44
|
Hi all, When I try to create a new relationship field in a datatype in the Object section of DBasis, the 'Choose Relationship' menu is empty - how can this menu be made to show the relationships defined in the Relationships section? Kind regards, Adrian ___ Adrian Columb Communication Consultant, CBDagency http://www.CBDagency.com/ Communication - Branding - Design |
|
From: Randum I. <ia...@ra...> - 2003-07-18 12:05:12
|
Hi Sandy, thanks for getting back to me. I understand what you mean and it is quite odd that the sunrise field was in the db dump but the sunset one wasn't! At least at my end! I will check the dump when I get in tonight as I am sure I inserted it correctly. At least it isn't harmful this time! :o) Cheers, Ian. > Howdy- > > In preparation for our release of a full-fledged CMS, the Context app > now checks for some of the fields required by it. The errors are > harmless, but if you'd like to make them disappear you can add fields > named "sunrise" and "sunset" to all your objects. The relevant fields > should be in the DB dump (oddly enough entitled 'sunrise' and 'sunset'). > > They are meant as publish and expire dates. As long as you don't make > them required, it won't affect anything else--there is no built-in > support for them in the classes you use to build applications. > > Thanks, > Sandy > > On Friday, July 18, 2003, at 05:53 AM, Randum Ian wrote: > >> Morning guys, I updated Syntax on our server to the latest CVS version >> and >> I re-did the db using the sql file. >> >> When I use Context to look at the Content datatype I get the following >> error appearing underneth the [Add Content] link on the main part of >> the >> page. >> >> ---[snip]--- >> Warning: [PxDB] Could not find a matching field for this object: >> sunset in >> /home/danceportal/PxDB/classes/pxdb.class.php on line 151 >> >> Warning: [PxDB] Could not find a matching field for this object: >> sunset in >> /home/danceportal/PxDB/classes/pxdb.class.php on line 151 >> ---[snip]--- >> >> Please can you advise on how I can rectify this problem. > -- > Sandy Smith, Senior Programmer > Forum One Communications > <ss...@fo...> > http://www.forumone.com/ > tel. (703) 548-1855 x28 Randum Ian ia...@ra... CBDagency Web Consultant http://www.cbdagency.com DancePortalGlobal Webmaster http://www.danceportalglobal.com |
|
From: Sandy S. <ss...@fo...> - 2003-07-18 11:13:35
|
Howdy- In preparation for our release of a full-fledged CMS, the Context app now checks for some of the fields required by it. The errors are harmless, but if you'd like to make them disappear you can add fields named "sunrise" and "sunset" to all your objects. The relevant fields should be in the DB dump (oddly enough entitled 'sunrise' and 'sunset'). They are meant as publish and expire dates. As long as you don't make them required, it won't affect anything else--there is no built-in support for them in the classes you use to build applications. Thanks, Sandy On Friday, July 18, 2003, at 05:53 AM, Randum Ian wrote: > Morning guys, I updated Syntax on our server to the latest CVS version > and > I re-did the db using the sql file. > > When I use Context to look at the Content datatype I get the following > error appearing underneth the [Add Content] link on the main part of > the > page. > > ---[snip]--- > Warning: [PxDB] Could not find a matching field for this object: > sunset in > /home/danceportal/PxDB/classes/pxdb.class.php on line 151 > > Warning: [PxDB] Could not find a matching field for this object: > sunset in > /home/danceportal/PxDB/classes/pxdb.class.php on line 151 > ---[snip]--- > > Please can you advise on how I can rectify this problem. -- Sandy Smith, Senior Programmer Forum One Communications <ss...@fo...> http://www.forumone.com/ tel. (703) 548-1855 x28 |
|
From: Randum I. <ia...@ra...> - 2003-07-18 09:36:12
|
Morning guys, I updated Syntax on our server to the latest CVS version and I re-did the db using the sql file. When I use Context to look at the Content datatype I get the following error appearing underneth the [Add Content] link on the main part of the page. ---[snip]--- Warning: [PxDB] Could not find a matching field for this object: sunset in /home/danceportal/PxDB/classes/pxdb.class.php on line 151 Warning: [PxDB] Could not find a matching field for this object: sunset in /home/danceportal/PxDB/classes/pxdb.class.php on line 151 ---[snip]--- Please can you advise on how I can rectify this problem. Cheers, Randum Ian ia...@ra... CBDagency Web Consultant http://www.cbdagency.com DancePortalGlobal Webmaster http://www.danceportalglobal.com |
|
From: Nyk C. <ny...@fo...> - 2003-06-02 17:17:05
|
Hi Ian: Here's some pointers to what the sections of the API documentation represent: Randum Ian wrote: >Morning guys, > >I have been working my way thru the API Docs over the weekend and I have >more specifically working with the pxdb_input page. > >I have noticed that the page (and others if I remember correctly) is split >into the following sections. > >pxdb_input > The class is called pxdb_input and the documentation shows the object tree or hierarchy. Object tree for pxdb_input is: pxdb_data <http://syntax.forumone.com/docs/api/pxdb_data.html> | +-- pxdb_confront <http://syntax.forumone.com/docs/api/pxdb_confront.html> | +-- pxdb_input This means that pxdb_input (at the bottom of the inheritence tree) extends the pxdb_confront class, which in turn extends the pxdb_data class. What this means in practice is that the base class pxdb_data defines a number of fields or attributes and methods and the pxdb_confront class extends this base class adding it's own fields and methods while at the same time inheriting the fields and methods from pxdb_data. Finally, pxdb_input extends the pxdb_confront class adding even more fields and methods. The cool thing is that you could, given the proper motivation, extend the pxdb_input class and add your own fields and methods or even override methods from the base class if you needed to change functionality. This is the power of object-oriented programming. So for pxdb_input you can set or reset the datatype on a pxdb_input object using the set_datatype() method even though that method is not defined in the pxdb_input class - it is inherited from the pxdb_data base class. >Methods inherited from pxdb_confront > This is the list of methods that get inherited from the pxdb_confront class - it doesn't really matter too much to you where the method is defined, only that it is a method that you can call on your pxdb_input object. If you click on the link for get_form_element_name() it will take you to the API doc page for the pxdb_confront class. >Methods inherited from pxdb_data > Same as above only this lists the methods inherited from the pxdb_data class. >Public Method Summary > Public methods are those methods that you as a programmer using the API can safely use in your own applications. They are the public interface that we as the API designers promise not to break, because we don't want you to have to rewrite your applications everytime we make improvements to the system. Public methods you can think of as being 'safe to use'. >Private Method Summary > Private methods are those that are used internally by the API classes themselves. Some OOP languages such as Java or C++ will throw errors or exceptions if you try to call private methods. PHP however does not ensure privacy. However, marking methods as private helps us to communicate what methods you should not call because we make no guarantee that we will not remove the method or rename it or change it in some other way that would break any external script that uses it. Private methods you can think of as being 'unsafe to use'. >Fields inherited from pxdb_confront > The same thing as inherited methods only these are fields that are inherited (in general you should use accessor methods to change the values of fields, unless no accessor method is provided). >Fields inherited from pxdb_data > ditto >Public Field Summary > Public fields are 'safe to use' - just like public methods are 'safe to use' >Private Field Summary > Private fields 'unsafe to use' ... >Public Method Details > This is just the details section summarized in the Public Method Summary. >Private Method Details >Public Field Details >Private Field Details > You probably get the picture now. >I have started to understand what each section means but I would >appreciate a professional opinion and a short *dummified* explanation. > > Hope that helps >Would that be possible? > Nah... not a chance :-) Regards Nyk |
|
From: Randum I. <ia...@ra...> - 2003-06-02 12:33:39
|
Morning guys, I have been working my way thru the API Docs over the weekend and I have more specifically working with the pxdb_input page. I have noticed that the page (and others if I remember correctly) is split into the following sections. pxdb_input Methods inherited from pxdb_confront Methods inherited from pxdb_data Public Method Summary Private Method Summary Fields inherited from pxdb_confront Fields inherited from pxdb_data Public Field Summary Private Field Summary Public Method Details Private Method Details Public Field Details Private Field Details I have started to understand what each section means but I would appreciate a professional opinion and a short *dummified* explanation. Would that be possible? Cheers, Randum Ian ia...@ra... DancePortalGlobal Webmaster http://www.danceportalglobal.com |
|
From: Sandy S. <ss...@fo...> - 2003-05-08 14:47:31
|
Absolutely you should be able to just drop in the replacement files and
just issue (if you haven't already)
ALTER TABLE typesfields CHANGE `unique` is_unique ENUM('Y','N') DEFAULT
'N';
in MySQL. Everything should work from then on out. That's how I did it
here for two sites.
If that *doesn't* work, let us know.
On Thursday, May 8, 2003, at 10:09 AM, Randum Ian wrote:
> Sandy, thanks for the useful advice. Would it be best for us to just
> reload
> the entire package including db schema and start again fresh now or
> can we
> just *patch* up the holes that we have found and it work swimmingly
> from
> here on in?
>
> Asking this as once it goes on launch I really don't want to have to
> start
> pulling it to pieces! ;o)
>
>> Hi Ian--
>>
>> The upgrade script should be called automagically when we increment a
>> version number in the release. Since most of the code is if'ed out by
>> a
>> comparison between the current release number and that stored in the
>> pxdb_prefs table, the only way to force it to happen is to decrement
>> that number. However that will likely cause errors as currently it
>> blindly changes column names that won't be there in a newer
>> installation. The likely result (I haven't tried it) would be it
>> quitting with a bunch of ugly errors. So that procedure is not
>> recommended.
>>
>> It may just be that we need to increment the version number every time
>> we affect the database schema (which should hopefully be somewhat rare
>> from here on out as I think the most problematic parts have been
>> fixed). That might require some re-thinking of the script, though.
>>
>> In any event, the only real change since 0.0.4 should be the
>> unique->is_unique change. Once that's done, you shouldn't see problems
>> (originating from database structure issues, at least).
>>
>> Cheers,
>> Sandy
>>
>> On Thursday, May 8, 2003, at 09:45 AM, Randum Ian wrote:
>>
>>> Hi Sandy,
>>>
>>> Thanks for getting back to me. I am lead to believe that the CVS copy
>>> hasn't overwritten the original as I previously thought. I will make
>>> sure
>>> that I download the latest CVS version tonight and rename the old one
>>> before copying it across I should have the updated version on there.
>>>
>>> 1 question I do have is when do I use the upgrade.php script you
>>> mention
>>> below? Everytime I download from CVS or major updates? Would this go
>>> some
>>> way to solving my error?
>>>
>>> Regards, Ian.
>>>
>>>> I assume this is in the relationships table. I'm not sure why the
>>>> fields dt1 and dt2 should be deleted, but they were never used by
>>>> the
>>>> system--it was an experimental feature that was never completed, so
>>>> I
>>>> took it out. It should be fine to leave them out of that table as
>>>> they don't do anything.
>>>>
>>>> Now, if this is causing you database errors, be sure of two things:
>>>>
>>>> a) that the CVS copies are really overwriting these files. The most
>>>> offensive ones are in PxDB/classes/metadata and in DBasis/datatypes.
>>>>
>>>> b) that you re-name the 'unique' field in typesfields to
>>>> 'is_unique'.
>>>> That isn't caught by the upgrade script currently.
>>>>
>>>> I have that code working on three sites in-house. If you still get
>>>> errors, post the text of them here and I'll take a look at them.
>>>>
>>>> On Thursday, May 8, 2003, at 04:21 AM, Randum Ian wrote:
>>>>
>>>>> Morning guys,
>>>>>
>>>>> We are in the process of implementing Syntax on our server now and
>>>>> we have
>>>>> updated to the latest version on CVS as of Tuesday. We are having
>>>>> serious
>>>>> problems with fields not being found in our database when we try to
>>>>> add records with Dbasis namely dt1 and dt2. We add these fields
>>>>> back
>>>>> but they
>>>>> disappear just as fast. I noticed that this problem was noted and a
>>>>> fix was
>>>>> implemented so would it be best to just delete the db and apply the
>>>>> sql file and make a fresh instance of the tables. Would the errors
>>>>> go away are
>>>>> is it something else that we should be noting?
>>>>>
>>>>> Regards,
>>>>> Randum Ian
>>>>> ia...@ra...
>>>>> DancePortalGlobal Webmaster
>>>>> http://www.danceportalglobal.com
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa
>>>>> Clara The only event dedicated to issues related to Linux
>>>>> enterprise
>>>>> solutions
>>>>> www.enterpriselinuxforum.com
>>>>>
>>>>> _______________________________________________
>>>>> Websyntax-users mailing list
>>>>> Web...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/websyntax-users
>>>>>
>>>>>
>>>> --
>>>> Sandy Smith, Senior Programmer
>>>> Forum One Communications
>>>> <ss...@fo...>
>>>> http://www.forumone.com/
>>>> tel. (703) 548-1855 x28
>>>
>>>
>>> Randum Ian
>>> ia...@ra...
>>> DancePortalGlobal Webmaster
>>> http://www.danceportalglobal.com
>>>
>>>
>> --
>> Sandy Smith, Senior Programmer
>> Forum One Communications
>> <ss...@fo...>
>> http://www.forumone.com/
>> tel. (703) 548-1855 x28
>
>
> Randum Ian
> ia...@ra...
> DancePortalGlobal Webmaster
> http://www.danceportalglobal.com
>
>
--
Sandy Smith, Senior Programmer
Forum One Communications, Inc.
ss...@fo...
tel. 703-548-1855 x28
http://www.forumone.com/
|
|
From: Randum I. <ia...@ra...> - 2003-05-08 13:44:51
|
Sandy, thanks for the useful advice. Would it be best for us to just reload the entire package including db schema and start again fresh now or can we just *patch* up the holes that we have found and it work swimmingly from here on in? Asking this as once it goes on launch I really don't want to have to start pulling it to pieces! ;o) > Hi Ian-- > > The upgrade script should be called automagically when we increment a > version number in the release. Since most of the code is if'ed out by a > comparison between the current release number and that stored in the > pxdb_prefs table, the only way to force it to happen is to decrement > that number. However that will likely cause errors as currently it > blindly changes column names that won't be there in a newer > installation. The likely result (I haven't tried it) would be it > quitting with a bunch of ugly errors. So that procedure is not > recommended. > > It may just be that we need to increment the version number every time > we affect the database schema (which should hopefully be somewhat rare > from here on out as I think the most problematic parts have been > fixed). That might require some re-thinking of the script, though. > > In any event, the only real change since 0.0.4 should be the > unique->is_unique change. Once that's done, you shouldn't see problems > (originating from database structure issues, at least). > > Cheers, > Sandy > > On Thursday, May 8, 2003, at 09:45 AM, Randum Ian wrote: > >> Hi Sandy, >> >> Thanks for getting back to me. I am lead to believe that the CVS copy >> hasn't overwritten the original as I previously thought. I will make >> sure >> that I download the latest CVS version tonight and rename the old one >> before copying it across I should have the updated version on there. >> >> 1 question I do have is when do I use the upgrade.php script you >> mention >> below? Everytime I download from CVS or major updates? Would this go >> some >> way to solving my error? >> >> Regards, Ian. >> >>> I assume this is in the relationships table. I'm not sure why the >>> fields dt1 and dt2 should be deleted, but they were never used by the >>> system--it was an experimental feature that was never completed, so I >>> took it out. It should be fine to leave them out of that table as >>> they don't do anything. >>> >>> Now, if this is causing you database errors, be sure of two things: >>> >>> a) that the CVS copies are really overwriting these files. The most >>> offensive ones are in PxDB/classes/metadata and in DBasis/datatypes. >>> >>> b) that you re-name the 'unique' field in typesfields to 'is_unique'. >>> That isn't caught by the upgrade script currently. >>> >>> I have that code working on three sites in-house. If you still get >>> errors, post the text of them here and I'll take a look at them. >>> >>> On Thursday, May 8, 2003, at 04:21 AM, Randum Ian wrote: >>> >>>> Morning guys, >>>> >>>> We are in the process of implementing Syntax on our server now and >>>> we have >>>> updated to the latest version on CVS as of Tuesday. We are having >>>> serious >>>> problems with fields not being found in our database when we try to >>>> add records with Dbasis namely dt1 and dt2. We add these fields back >>>> but they >>>> disappear just as fast. I noticed that this problem was noted and a >>>> fix was >>>> implemented so would it be best to just delete the db and apply the >>>> sql file and make a fresh instance of the tables. Would the errors >>>> go away are >>>> is it something else that we should be noting? >>>> >>>> Regards, >>>> Randum Ian >>>> ia...@ra... >>>> DancePortalGlobal Webmaster >>>> http://www.danceportalglobal.com >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa >>>> Clara The only event dedicated to issues related to Linux enterprise >>>> solutions >>>> www.enterpriselinuxforum.com >>>> >>>> _______________________________________________ >>>> Websyntax-users mailing list >>>> Web...@li... >>>> https://lists.sourceforge.net/lists/listinfo/websyntax-users >>>> >>>> >>> -- >>> Sandy Smith, Senior Programmer >>> Forum One Communications >>> <ss...@fo...> >>> http://www.forumone.com/ >>> tel. (703) 548-1855 x28 >> >> >> Randum Ian >> ia...@ra... >> DancePortalGlobal Webmaster >> http://www.danceportalglobal.com >> >> > -- > Sandy Smith, Senior Programmer > Forum One Communications > <ss...@fo...> > http://www.forumone.com/ > tel. (703) 548-1855 x28 Randum Ian ia...@ra... DancePortalGlobal Webmaster http://www.danceportalglobal.com |
|
From: Sandy S. <ss...@fo...> - 2003-05-08 13:37:20
|
Hi Ian-- The upgrade script should be called automagically when we increment a version number in the release. Since most of the code is if'ed out by a comparison between the current release number and that stored in the pxdb_prefs table, the only way to force it to happen is to decrement that number. However that will likely cause errors as currently it blindly changes column names that won't be there in a newer installation. The likely result (I haven't tried it) would be it quitting with a bunch of ugly errors. So that procedure is not recommended. It may just be that we need to increment the version number every time we affect the database schema (which should hopefully be somewhat rare from here on out as I think the most problematic parts have been fixed). That might require some re-thinking of the script, though. In any event, the only real change since 0.0.4 should be the unique->is_unique change. Once that's done, you shouldn't see problems (originating from database structure issues, at least). Cheers, Sandy On Thursday, May 8, 2003, at 09:45 AM, Randum Ian wrote: > Hi Sandy, > > Thanks for getting back to me. I am lead to believe that the CVS copy > hasn't overwritten the original as I previously thought. I will make > sure > that I download the latest CVS version tonight and rename the old one > before copying it across I should have the updated version on there. > > 1 question I do have is when do I use the upgrade.php script you > mention > below? Everytime I download from CVS or major updates? Would this go > some > way to solving my error? > > Regards, Ian. > >> I assume this is in the relationships table. I'm not sure why the >> fields dt1 and dt2 should be deleted, but they were never used by the >> system--it was an experimental feature that was never completed, so I >> took it out. It should be fine to leave them out of that table as they >> don't do anything. >> >> Now, if this is causing you database errors, be sure of two things: >> >> a) that the CVS copies are really overwriting these files. The most >> offensive ones are in PxDB/classes/metadata and in DBasis/datatypes. >> >> b) that you re-name the 'unique' field in typesfields to 'is_unique'. >> That isn't caught by the upgrade script currently. >> >> I have that code working on three sites in-house. If you still get >> errors, post the text of them here and I'll take a look at them. >> >> On Thursday, May 8, 2003, at 04:21 AM, Randum Ian wrote: >> >>> Morning guys, >>> >>> We are in the process of implementing Syntax on our server now and we >>> have >>> updated to the latest version on CVS as of Tuesday. We are having >>> serious >>> problems with fields not being found in our database when we try to >>> add records with Dbasis namely dt1 and dt2. We add these fields back >>> but they >>> disappear just as fast. I noticed that this problem was noted and a >>> fix was >>> implemented so would it be best to just delete the db and apply the >>> sql file and make a fresh instance of the tables. Would the errors go >>> away are >>> is it something else that we should be noting? >>> >>> Regards, >>> Randum Ian >>> ia...@ra... >>> DancePortalGlobal Webmaster >>> http://www.danceportalglobal.com >>> >>> >>> >>> ------------------------------------------------------- >>> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara >>> The only event dedicated to issues related to Linux enterprise >>> solutions >>> www.enterpriselinuxforum.com >>> >>> _______________________________________________ >>> Websyntax-users mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/websyntax-users >>> >>> >> -- >> Sandy Smith, Senior Programmer >> Forum One Communications >> <ss...@fo...> >> http://www.forumone.com/ >> tel. (703) 548-1855 x28 > > > Randum Ian > ia...@ra... > DancePortalGlobal Webmaster > http://www.danceportalglobal.com > > -- Sandy Smith, Senior Programmer Forum One Communications <ss...@fo...> http://www.forumone.com/ tel. (703) 548-1855 x28 |
|
From: Randum I. <ia...@ra...> - 2003-05-08 13:20:51
|
Hi Sandy, Thanks for getting back to me. I am lead to believe that the CVS copy hasn't overwritten the original as I previously thought. I will make sure that I download the latest CVS version tonight and rename the old one before copying it across I should have the updated version on there. 1 question I do have is when do I use the upgrade.php script you mention below? Everytime I download from CVS or major updates? Would this go some way to solving my error? Regards, Ian. > I assume this is in the relationships table. I'm not sure why the > fields dt1 and dt2 should be deleted, but they were never used by the > system--it was an experimental feature that was never completed, so I > took it out. It should be fine to leave them out of that table as they > don't do anything. > > Now, if this is causing you database errors, be sure of two things: > > a) that the CVS copies are really overwriting these files. The most > offensive ones are in PxDB/classes/metadata and in DBasis/datatypes. > > b) that you re-name the 'unique' field in typesfields to 'is_unique'. > That isn't caught by the upgrade script currently. > > I have that code working on three sites in-house. If you still get > errors, post the text of them here and I'll take a look at them. > > On Thursday, May 8, 2003, at 04:21 AM, Randum Ian wrote: > >> Morning guys, >> >> We are in the process of implementing Syntax on our server now and we >> have >> updated to the latest version on CVS as of Tuesday. We are having >> serious >> problems with fields not being found in our database when we try to >> add records with Dbasis namely dt1 and dt2. We add these fields back >> but they >> disappear just as fast. I noticed that this problem was noted and a >> fix was >> implemented so would it be best to just delete the db and apply the >> sql file and make a fresh instance of the tables. Would the errors go >> away are >> is it something else that we should be noting? >> >> Regards, >> Randum Ian >> ia...@ra... >> DancePortalGlobal Webmaster >> http://www.danceportalglobal.com >> >> >> >> ------------------------------------------------------- >> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara >> The only event dedicated to issues related to Linux enterprise >> solutions >> www.enterpriselinuxforum.com >> >> _______________________________________________ >> Websyntax-users mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/websyntax-users >> >> > -- > Sandy Smith, Senior Programmer > Forum One Communications > <ss...@fo...> > http://www.forumone.com/ > tel. (703) 548-1855 x28 Randum Ian ia...@ra... DancePortalGlobal Webmaster http://www.danceportalglobal.com |
|
From: Sandy S. <ss...@fo...> - 2003-05-08 13:16:38
|
I assume this is in the relationships table. I'm not sure why the fields dt1 and dt2 should be deleted, but they were never used by the system--it was an experimental feature that was never completed, so I took it out. It should be fine to leave them out of that table as they don't do anything. Now, if this is causing you database errors, be sure of two things: a) that the CVS copies are really overwriting these files. The most offensive ones are in PxDB/classes/metadata and in DBasis/datatypes. b) that you re-name the 'unique' field in typesfields to 'is_unique'. That isn't caught by the upgrade script currently. I have that code working on three sites in-house. If you still get errors, post the text of them here and I'll take a look at them. On Thursday, May 8, 2003, at 04:21 AM, Randum Ian wrote: > Morning guys, > > We are in the process of implementing Syntax on our server now and we > have > updated to the latest version on CVS as of Tuesday. We are having > serious > problems with fields not being found in our database when we try to add > records with Dbasis namely dt1 and dt2. We add these fields back but > they > disappear just as fast. I noticed that this problem was noted and a > fix was > implemented so would it be best to just delete the db and apply the sql > file and make a fresh instance of the tables. Would the errors go away > are > is it something else that we should be noting? > > Regards, > Randum Ian > ia...@ra... > DancePortalGlobal Webmaster > http://www.danceportalglobal.com > > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise > solutions > www.enterpriselinuxforum.com > > _______________________________________________ > Websyntax-users mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/websyntax-users > > -- Sandy Smith, Senior Programmer Forum One Communications <ss...@fo...> http://www.forumone.com/ tel. (703) 548-1855 x28 |
|
From: Randum I. <ia...@ra...> - 2003-05-08 07:56:09
|
Morning guys, We are in the process of implementing Syntax on our server now and we have updated to the latest version on CVS as of Tuesday. We are having serious problems with fields not being found in our database when we try to add records with Dbasis namely dt1 and dt2. We add these fields back but they disappear just as fast. I noticed that this problem was noted and a fix was implemented so would it be best to just delete the db and apply the sql file and make a fresh instance of the tables. Would the errors go away are is it something else that we should be noting? Regards, Randum Ian ia...@ra... DancePortalGlobal Webmaster http://www.danceportalglobal.com |
|
From: Nyk C. <nc...@fo...> - 2003-04-30 22:01:59
|
I have added a new WYSIWYG editor widget to Syntax. This uses a DHTML based editor called Easy Web Editor (EWE) . http://www.openmymind.net/products/ewe/index.php This is licensed under the LGPL and so is compatible with Syntax licensing. This widget loads quicker than eKit (the Java applet HTML editor currently implemented as the html_wysiwyg plugin) and it also support cut-and-paste from Microsoft Office documents such as Word and Excel. However, it will only work on Windows with IE 5.5. The new plugin 'easy_editor' provides a standard HTML text area with a link 'Edit with HTML Editor' that appears above the text area. This will only show if the browser is Windows/IE 5.5. Since this widget solution uses a popup window and field updates are done using Javascript DOM it will be relatively easy to add a Mozilla-based rich HTML editor popup that will be called if the user has Mozilla capabilities. Added new class: pxdb_browser.class.php This class provides a simple interface to browser and platform information. It can be imported into modules by using the pxdb_import() global function: pxdb_import('tools.pxdb_browser/); $browser = new BrowserInfo(); if ($browser->isWindows() && $browser->isMac() && $browser->getVersion() >= 5.0) { // Do stuff specific to Mac IE 5.0 browsers } Eventually other browser information (such as Browser capabilities, files accepted, languages etc.) will be added to this class. |
|
From: Sandy S. <ss...@fo...> - 2003-04-30 16:25:47
|
Hi Adrian-- I took a brief look at your table. I may be able to look longer tonight for more specific suggestions, but for the moment: You may want to consider using Syntax's facility for relating datatypes to one another. The clearest areas I see for this are your Area/Side 1 Name and Info fields. Instead I would suggest using DBasis to set up two new objects: Area and Side. Then define fields for each, Name and Information (probably mapped to name and desc1), and so on. Then define two new relationships: Event to Area and Music to Side. Then modify your Event datatype to have an Areas attribute (clicking the Multiple checkbox) and select the Event to Area relationship. Modify the Music datatype to have a Sides attribute (clicking the Multiple checkbox) and select the Music to Side relationship. The consuming code is a little more complex, but as you will see from the API the pxdb_record object is fairly good about giving you shortcuts to get related objects. The advantage of this approach, besides making your records table much less complex, is that it allows not just 4 areas or sides, but n areas and n sides. To get user submissions, you can create a wizard to allow people too submit an event and then add areas until they're done. In Context, your admins can create the areas and sides and then modify the Event and Music objects to include them as needed. One note is that you will want to make the relationship bidirectional, so you can add an Event single relationship in the Area datatype, and create your additional areas and relate them to their event in one step. It's useful to keep the relationship in the Event object so you can both see associated areas when you are editing the Event object and use an event pxdb_record object to get related Areas. If you do a similar decomposition of your other datatypes (or fields in the Music and Event datatypes, such as related shopping items), you might avoid some of this complexity. However, I do find that occasional projects will force me to add one or two extra columns to the records table. Hope that helps, Sandy On Sunday, April 27, 2003, at 09:15 AM, Adrian Columb wrote: > Hi Syntax users, > > We've recently installed Syntax on our server and have been planning > the > database according to our website's content needs. We've been > struggling to > understand the best way to customise the software and would really > appreciate some help. Attached is a word document containing a table > that > outlines our plan so far for the database tables, indicating the > fields of > each datatype, and our basic database fields as well. > > The first column - Database fields is the fields of the database. The > second > column - Fieldtype is the type of content that field will contain. The > third > column - Event DataType Field and other columns with '+' or 'x' in > indicate > whether that database field is relevant for each of the datatypes. The > Event > Datatype Field Description column and Music DB field description, > etc indicate what that database field is used for in each datatype. > > I understand that Syntax works best is for there to be a minimum > number of > fields in the database by repurposing fields that are used for a > specific > purpose in one datatype (Eg, the Events datatype), for use in another > datatype (Eg, the Music datatype). That occurs for DB field Date3 in > the > attached document - the fields are called different names in the > different > datatypes. > > So basically I have tried to have the least number of DB fields by > repurposing the fields used by the different datatypes in other > datatypes to > some extent but am finding it a real mental exercise. > > Would anyone mind taking a look at the document and checking out the DB > fields in the left hand side column labelled "MUSIC and EVENTS", and > the > items labelled "PEOPLE, PLACES, and ORGANISATIONS", and see if you can > see > which if any of the fields can be re-purposed between these two groups > of > datatypes? Or if anyone can offer a better strategy for this > normaization > process that would be fantastic. I also understand that Syntax needs > datatypes to have identical field types for this to work. > > All of this seems very difficult to do quickly, and our project's > deadline > is very soon. I'm guessing we could just set up the db with as many > fields > as needed by the different datatypes (even if some fields will be used > in > only one or two datatypes) and then cut out irrelevant fields > one-by-one as > we find > matches along the way. Is that correct (or do we absolutely need to > repurpose all fields among the different datatypes wherever possible > from > the very start)? > > Are we on the right track? > > Regards, > > Adrian > <DPGSyntaxDBfieldsanddatatypestable.doc> -- Sandy Smith, Senior Programmer Forum One Communications, Inc. ss...@fo... tel. 703-548-1855 x28 http://www.forumone.com/ |
|
From: Adrian C. <ad...@da...> - 2003-04-27 13:21:13
|
Hi Syntax users, We've recently installed Syntax on our server and have been planning the database according to our website's content needs. We've been struggling to understand the best way to customise the software and would really appreciate some help. Attached is a word document containing a table that outlines our plan so far for the database tables, indicating the fields of each datatype, and our basic database fields as well. The first column - Database fields is the fields of the database. The second column - Fieldtype is the type of content that field will contain. The third column - Event DataType Field and other columns with '+' or 'x' in indicate whether that database field is relevant for each of the datatypes. The Event Datatype Field Description column and Music DB field description, etc indicate what that database field is used for in each datatype. I understand that Syntax works best is for there to be a minimum number of fields in the database by repurposing fields that are used for a specific purpose in one datatype (Eg, the Events datatype), for use in another datatype (Eg, the Music datatype). That occurs for DB field Date3 in the attached document - the fields are called different names in the different datatypes. So basically I have tried to have the least number of DB fields by repurposing the fields used by the different datatypes in other datatypes to some extent but am finding it a real mental exercise. Would anyone mind taking a look at the document and checking out the DB fields in the left hand side column labelled "MUSIC and EVENTS", and the items labelled "PEOPLE, PLACES, and ORGANISATIONS", and see if you can see which if any of the fields can be re-purposed between these two groups of datatypes? Or if anyone can offer a better strategy for this normaization process that would be fantastic. I also understand that Syntax needs datatypes to have identical field types for this to work. All of this seems very difficult to do quickly, and our project's deadline is very soon. I'm guessing we could just set up the db with as many fields as needed by the different datatypes (even if some fields will be used in only one or two datatypes) and then cut out irrelevant fields one-by-one as we find matches along the way. Is that correct (or do we absolutely need to repurpose all fields among the different datatypes wherever possible from the very start)? Are we on the right track? Regards, Adrian |
|
From: Nyk C. <ny...@fo...> - 2003-04-07 16:55:35
|
Hi Ian: You should avoid manipulating the database tables directly from the mysql client (e.g. PHPMyAdmin et.c) since there is a danger that you can break something (you should only touch the tables directly if you know what you are doing). er However, there are a number of ways in which you can add content to your Syntax site. a. You can add data from the 'data' tab in DBasis (should really only do this for testing and debugging purposes). b. Use the Context admin interface. c. Create user input pages using the Syntax Input Layer of the SDK (or API). I recommend that you read the documentation on the Input Layer to get an overview on how to develop user input pages and custom admin pages etc. http://syntax.forumone.com/wiki/index.php?page=InputLayer For more detailed understanding review the API documentation. http://syntax.forumone.com/docs/api/ In particular you should familiarize yourself with the pxdb_input class for rendering input forms, and pxdb_commit for saving user input into the Syntax repository. Hope that helps Nyk Note: I have cc'd this to the user list. On Monday, April 7, 2003, at 09:47 AM, Randum Ian wrote: > Hi Nyk, I was just wondering about inputting data into the Syntax. You > said > not to manually enter the data does that mean you can only use Context > or > is there a class that allows me to customise the forms? > > Regards, Ian. > > > |
|
From: Nyk C. <nc...@fo...> - 2003-03-28 21:57:16
|
-----Original Message----- From: Randum Ian [mailto:ia...@ra...] Sent: Friday, March 28, 2003 2:24 PM To: 'Nyk Cowham' Cc: ad...@da... Subject: RE: Syntax Problems Hi Nik, I didn't realise that sorry. I have moved it out of the Dbasis directory now but I was still having the same problems but I now realise why it wasn't working and it might be something worth putting in the Wiki or Documents? The error message I got was to say that /list.php is not found on the server ie a 404. I went into the .htaccess file and made the /list.php into http://www.danceportalglobal.com/context/list.php as you can see it is an absolute reference not a relative one. This could be due to the setup of our webserver or whatever but it now works fine! I am going to produce a document detailing how I installed it on our server as part of a project that the Editor of DancePortalGlobal is using Syntax for so if he agrees would you like to see a copy of the final article? I thank you for your kind patience, Ian. -----Original Message----- From: Nyk Cowham [mailto:nc...@fo...] Sent: 28 March 2003 18:37 To: Randum Ian Subject: RE: Syntax Problems > "Assuming you want the Context base directory to be /var/www/html/admin > and you have unpacked the PHlexDB archive. Note: the Context files need > to be under your web root." > > Nik, isn't this a contradiction of terms? It says to put the directory > in the html directory which is the webroot but then says not to??? You want to put your PxDB components in a location that is not accessible by the web. However the Context and DBasis tools do need to be in a public location, renamed as 'admin' or whatever. Having PxDB in a non-accessible area simply improves security. > I have installed Context in /home/danceportal/www/dbasis/context so that > you can see it here http://www.danceportalglobal.com/dbasis/context as > per the email Adrian has sent. > > The Config file has been filled in and the .htaccess file has been > renamed and is currently in the Context dir. I haven't change this in > any way. It is almost definitely a problem with your Rewrite rules: The first link would translate as: http://www.danceportalglobal.com/dbasis/context/list.php?object=person and you can see that the page renders properly. This corresponds to the rewrite rule: RewriteRule ^object/([^/]+)/? /list.php?object=$1 [L,qsappend] After looking at this more closely I can see why the rewrites are not working. It is because you have the context app within the dbasis directory. Try moving it to: http://www.danceportalglobal.com/context/ The reason this is breaking in the current configuration is that dbasis has a directory called 'object' and we are doing a rewrite using the keyword 'object' in context. I am 99% sure making this change will fix your problem. Let me know if you are still having issues. > Does this shed any light on the matter? I hope that does it for you. Nyk. > Regards, Ian. > > -----Original Message----- > From: Nyk Cowham [mailto:nc...@fo...] > Sent: 28 March 2003 16:44 > To: Randum Ian > Subject: RE: Syntax Problems > > Hi Ian: > > > I have installed the Syntax classes onto the server but when I > > have logged > > into Context and click the links down the left-hand-side I get page > not > > found errors. Could you give me an idea of what I have done wrong > > so that I > > can correct it? > > Did you do all these things? > > * Move the files > * -------------- > > Assuming you want the Context base directory to be > /var/www/html/admin > and you have unpacked > the PHlexDB archive. Note: the Context files need to be under your > web > root. > > Move the directory to the desired destination: > $> mv Context /var/www/html/ > $> cd /var/www/html > > Rename Context to admin: > $> mv Context admin > > * Create a config.inc.php > * ----------------------- > > You will need to modify the config.inc.php-dist file located in the > config/ directory. (e.g. > /var/www/html/admin/config/ in our example) and rename it > config.inc.php. > > There are instructions in this file that explain what needs to be > specified. Essentially you > will need to tell the app where the PxDB package is located and how > to > connect to the > database server. > > * Create Rewrite Rules > * -------------------- > > You probably want to just rename the htaccess-dist file to .htaccess > (or > merge contents into > your already-existing .htaccess file -- if you have Apache setup to > allow rewrite rules in > your .htaccess file. Otherwise you'll want to enter these rewrite > rules > in your Apache > configuration: > > RewriteEngine On > RewriteRule ^object/[^/]+/([^/]+)/([^/]+)/? > /list.php?parent=$1&object=$2 [L,qsappend] > RewriteRule ^object/[^/]+/([^/]+)/? /detail.php?id=$1 > [L,qsappend] > RewriteRule ^object/([^/]+)/? /list.php?object=$1 > [L,qsappend] > > * Symlink to pxdb_www/ > * -------------------- > > In your Context root directory, create a symbolic link to the > pxdb_www folder in the PxDB > root directory. This directory is necessary for some form > widgets > which depend on javascript > libraries or other http included content. E.g. > > $> cd /var/www/html/admin > $> ln -s /var/www/pxdb/pxdb_www pxdb_www > > My guess is that you have either not symlinked correctly or there is a > problem with your rewrite rules. Let me know if you followed all these > instructions - if you did and it is still not behaving I will be happy > to > have a look at your configuration and troubleshoot it for you. > > > Also is there a list I can join where I can get help and ideas on > using > > these classes? > > Yes there is a users list hosted by sourceforge: > > http://lists.sourceforge.net/lists/listinfo/websyntax-users > > You can subscribe to that list via the webpage link above. > > Good luck! > > Nyk > > > Kind Regards, Ian. > > > > > > > |
|
From: Nyk C. <nc...@fo...> - 2003-03-28 21:57:13
|
> Hi Nyk, > > I think that will probably be fine however I'm meeting with most of the > project team tomorrow and I'd like to run it by them also and > will then let > you know a decision on this. Cheers again for your help - we are checking > our Apache configuration at present and will let you know how it goes. > DancePortalGlobal webmaster Ian Roke (who has been in touch with you > recently) might also email you again for further assistance. Hi Adrian: I have been communicating with Ian and I'm pretty certain I have spotted the problem (the context app cannot be contained in the dbasis directory because of how the rewrite rules work). Once Ian makes the changes I suggested I think everything should work as expected. Again, I am more than willing to continue to provide support for you as needed - I will be using the issues that you may encounter to build our support resource (FAQ, documentation etc.) so I am pretty committed to ensuring the success of your project using Syntax. best wishes, Nyk |
|
From: Nyk C. <nc...@fo...> - 2003-03-28 21:52:19
|
Hi Adrian: I feel pretty certain the problem is that you have not setup the Apache Rewrite rules correctly. Please check the INSTALL.txt file in the Context directory and compare your rewrite rules in the htaccess-dist file. If you are going to use this file you can rename it .htaccess and it should work. Also make sure that mod_rewrite is installed in apache. Hope that helps. Nyk BTW - I would like to post your questions on the user mailing list so they get archived for future reference. Is that ok by you? > -----Original Message----- > From: Adrian Columb [mailto:ad...@da...] > Sent: Friday, March 28, 2003 11:54 AM > To: Nyk Cowham > Cc: web...@da... > Subject: Fw: [Fwd: Re: Syntax!!!] > Importance: High > > > Hi Nyk, > > We've now installed PxDB, DBasis, and Context and will soon begin > customisng > it to our site's needs. Was wondering if you know why the links on our > Context page don't work propperly? Its located at > http://www.danceportalglobal.com/dbasis/context which is governed by the > username ****. To get into the password > protected directory where it is stored use the username ***** and the > password *****. The DBasis program is installed at > http://www.danceportalglobal.com/dbasis which is password protected > with the same username/password. Smarty is also installed in the > right place > and so is ADOdb. Would you mind checking to see if we have it all set up > correctly, or let me know what we still need to do to finish off the > installation? Thanks very much in advance! > > Best, > > Adrian > > |
|
From: Nyk C. <nc...@fo...> - 2003-03-28 17:05:57
|
-----Original Message-----
From: Nyk Cowham [mailto:nc...@fo...]
Sent: Friday, March 28, 2003 11:44 AM
To: Randum Ian
Subject: RE: Syntax Problems
Hi Ian:
> I have installed the Syntax classes onto the server but when I
> have logged
> into Context and click the links down the left-hand-side I get page not
> found errors. Could you give me an idea of what I have done wrong
> so that I
> can correct it?
Did you do all these things?
* Move the files
* --------------
Assuming you want the Context base directory to be /var/www/html/admin
and you have unpacked
the PHlexDB archive. Note: the Context files need to be under your web
root.
Move the directory to the desired destination:
$> mv Context /var/www/html/
$> cd /var/www/html
Rename Context to admin:
$> mv Context admin
* Create a config.inc.php
* -----------------------
You will need to modify the config.inc.php-dist file located in the
config/ directory. (e.g.
/var/www/html/admin/config/ in our example) and rename it
config.inc.php.
There are instructions in this file that explain what needs to be
specified. Essentially you
will need to tell the app where the PxDB package is located and how to
connect to the
database server.
* Create Rewrite Rules
* --------------------
You probably want to just rename the htaccess-dist file to .htaccess (or
merge contents into
your already-existing .htaccess file -- if you have Apache setup to
allow rewrite rules in
your .htaccess file. Otherwise you'll want to enter these rewrite rules
in your Apache
configuration:
RewriteEngine On
RewriteRule ^object/[^/]+/([^/]+)/([^/]+)/?
/list.php?parent=$1&object=$2 [L,qsappend]
RewriteRule ^object/[^/]+/([^/]+)/? /detail.php?id=$1
[L,qsappend]
RewriteRule ^object/([^/]+)/? /list.php?object=$1
[L,qsappend]
* Symlink to pxdb_www/
* --------------------
In your Context root directory, create a symbolic link to the
pxdb_www folder in the PxDB
root directory. This directory is necessary for some form widgets
which depend on javascript
libraries or other http included content. E.g.
$> cd /var/www/html/admin
$> ln -s /var/www/pxdb/pxdb_www pxdb_www
My guess is that you have either not symlinked correctly or there is a
problem with your rewrite rules. Let me know if you followed all these
instructions - if you did and it is still not behaving I will be happy to
have a look at your configuration and troubleshoot it for you.
> Also is there a list I can join where I can get help and ideas on using
> these classes?
Yes there is a users list hosted by sourceforge:
http://lists.sourceforge.net/lists/listinfo/websyntax-users
You can subscribe to that list via the webpage link above.
Good luck!
Nyk
> Kind Regards, Ian.
>
>
|
|
From: Nyk C. <nc...@fo...> - 2003-03-28 16:16:29
|
Welcome to Syntax Users list: This list is the support forum for users of the Syntax SDK and Web Management System. Please feel free to post your questions to this list - it is archived and we will be building our FAQ from the sorts of support questions we are encountering. Please remember this is a community site and so we hope that as the Syntax user community grows that users who have successfully implemented their Syntax site will help their follow users who are just starting out. Nyk Cowham, Syntax Community Manager Forum One Communications http://syntax.forumone.com/ |
