[Solar-talk] Example Solar Code

Rodrigo Moraes rodrigo.moraes at gmail.com
Wed Mar 14 21:41:38 PDT 2007


On 3/15/07, Michael Soule wrote:
> I'm still feeling my way around Solar here, trying to get started, and could
> use a little help from anyone who has a moment.
>
> 1. Which Controller?
> I'm using AquaMDB as a guide (thank you Antti!) and it differs greatly from
> the Example Skeleton App on the Solar website. Specifically, Aqua uses a
> Front Controller while Skeleton uses a Page Controller. I'm guessing the
> front controller is for larger application type uses and the page controller
> is for simple websites build page by page. Is this correct? Can someone
> elaborate more?

I believe AquaMdb uses both (Front and Page controller). Let's see:
the Front Controller is the entrance door of your app. It will decide
which class will be called to build your application, and that's
almost all it does. It is the "front" door keeper or something like
that.

Once the Front Controller decides which class will be called (by
parsing the requested uri), it will instantiate a Page Controller (or,
being more clear: a subclass of a Page Controller, like Solar_App or a
Solar_App subclass, or even a more simple Page Controller build by
you), which will then check and execute the requested action. The
Page Controller carries your app logic, the "page" logic, manage the
View and other things.

> 2. Extended Users
> Is Solar flexible enough to allow the following... if so, any tips on
> implementing it?
>
> Example: I have a User class which maps to a users table. I also have an
> Ographers class (for photographers and videographers) which extends the User
> class. It also has an ographers table which has extra columns for
> ographer-specific data. Is the Solar_Auth package able to adapt to this kind
> of approach? Is there a better approach?

You can have any model/table schema you want for your users and
different kind of users. Solar_User/Solar_Auth will take care of
authenticating them, and for this you only need to have a basic users
table with some columns to store the authentication data (check
Solar_Auth_Adapter/Solar_Auth_Adapter_Sql for some hints). After the
user is authenticated, you can check inside your app which kind of
user it is, and load the data from the appropriate table.

> Btw, please let me know if this is not the appropriate place to post these
> types of questions.

This is *the* place. I tried to give you a better idea about the
subjects you mentioned, but if it was not clear don't hesitate to ask
for more details. :)

rodrigo moraes


More information about the solar-talk mailing list