Not complex at all.
The resume uploader is the "LinkOwner". Simply put
<%if LinkOwner%>
<%include resume.html%>
<%endif%>
Where resume.html can be a form.txt type of file, that allows update/edit as well as display.
And to allow the employer to view the records, you'd modify search.cgi or page.cgi just slightly to check
if ($USER->{paid_status}) { do.....} else {return 'You must become a member to use this feature.');
To build the site statically, would require a bit of thought, but just have static build ignore the <%resume%> fields completely, easy if you put them in a separate table linked to the Link Record by Link_ID and User table by Username.
The trick is how to set the <%paid_status%> flag, since that requires a bi-directional transaction gateway. ccBill or iBill might work, but you need to pass in the payment data, then have the script pass back the authorized info to another script that sets the User table field <%paid_status%>, and an <%expire%> field, just for completeness.
I've been living/breathing this portion of Links for 6 months now! Some things I still don't get, but this sort of toggle/access is easy with the current user records. It gets harder if you want to assign "editors", but simple status flags that set what options are available to a user/surfer/visitor are easy. Especially if the types of data (fields) are known before hand, as with a resume, which has a few required fields, then a searchable TEXT field.
I actually do that on most of my sites. Admin and Editors automatically see a button that allows them to click/edit a link from the display screens, and Link owners get shown more detail information, etc.
PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum
The resume uploader is the "LinkOwner". Simply put
<%if LinkOwner%>
<%include resume.html%>
<%endif%>
Where resume.html can be a form.txt type of file, that allows update/edit as well as display.
And to allow the employer to view the records, you'd modify search.cgi or page.cgi just slightly to check
if ($USER->{paid_status}) { do.....} else {return 'You must become a member to use this feature.');
To build the site statically, would require a bit of thought, but just have static build ignore the <%resume%> fields completely, easy if you put them in a separate table linked to the Link Record by Link_ID and User table by Username.
The trick is how to set the <%paid_status%> flag, since that requires a bi-directional transaction gateway. ccBill or iBill might work, but you need to pass in the payment data, then have the script pass back the authorized info to another script that sets the User table field <%paid_status%>, and an <%expire%> field, just for completeness.
I've been living/breathing this portion of Links for 6 months now! Some things I still don't get, but this sort of toggle/access is easy with the current user records. It gets harder if you want to assign "editors", but simple status flags that set what options are available to a user/surfer/visitor are easy. Especially if the types of data (fields) are known before hand, as with a resume, which has a few required fields, then a searchable TEXT field.
I actually do that on most of my sites. Admin and Editors automatically see a button that allows them to click/edit a link from the display screens, and Link owners get shown more detail information, etc.
PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum
