| 1 |
Paul de Vrieze wrote: |
| 2 |
> On Tuesday 03 February 2004 05:13, Eric Sammer wrote: |
| 3 |
> |
| 4 |
> One could offer an option to force the actions to be done. It would be |
| 5 |
> needed when users perform manual actions (but not in all cases). Of |
| 6 |
> course forcing actions will disable the back button so probably warrants |
| 7 |
> a warning. |
| 8 |
|
| 9 |
This is true and could be done. Again, in the interest of a working |
| 10 |
prototype in a reasonable amount of time, I would say we'll come back to |
| 11 |
this as adding it at a later date will be trivial. |
| 12 |
|
| 13 |
> It is the task of the frontend to either save up the actions or to send |
| 14 |
> them to the backend immediately. |
| 15 |
|
| 16 |
Actually, settings are stuffed into GLIInstallProfile by the controller |
| 17 |
(part of the back end). The profile (data) and arch template (logic) are |
| 18 |
then put together in a similar fashion as XML and XSL are combined (in |
| 19 |
theory, not implementation). Of course, this will probably have to |
| 20 |
perform differently when doing immediate fire actions, but is another |
| 21 |
reason why I'd like to get things working before we do things like that. |
| 22 |
|
| 23 |
> As long as the backend can perform |
| 24 |
> actions as soon as they are received (incomplete xml file) the backend |
| 25 |
> can handle whatever you want. |
| 26 |
|
| 27 |
Again, messaging is not done as XML, only state is saved that way. This |
| 28 |
means that the firing of actions will probably be done by the controller |
| 29 |
calling the logic from the arch templates immediately. This is more of |
| 30 |
an implementation issue but is something that will be kept in mind. |
| 31 |
|
| 32 |
-- |
| 33 |
Eric Sammer |
| 34 |
Gentoo Linux |
| 35 |
http://www.gentoo.org |
Archives