Open dy opened 8 years ago
Well I don’t see a big reason not placing that to settings-panel. Prama should not create panel, it should create some multipanel manager.
But what is a big purpose of it?
Therefore prama should be something conceptually different. Like manager. Like, don’t care about app setup, prama will take care of everything settings-related. Settings-panel is UI unit, prama is settings integration. What does that practically mean?
Well, prama could provide full-featured settings for any app. That is to say, tabs, launch pattern etc etc. As if you open chrome://settings.
In that, it has nothing much to do with settings-panel, it is a bit different project. Because settings page basically may contain any html. It is just static tabs manager. And the API is like
let settings = Prama({
general: {},
advanced: {},
});
Another possible direction - make UI tests runner. It will just load/save current test state and run lots of configs on a single component. Because settings usually are quite specific for applications, using settings-panel would be a bit uncreative.
Because testing with panel is ok, but it lacks of flow (we have to init conditions) and it lacks regression.
So basically, prama will run current panel setup session for testing flow, and should be able to set regression points.
Reasons for prama, differentiating it from the panel. Otherwise prama is not needed.
{type: 'group', content: Panel}
or something. Anyways, what prama is better than settings-panel for that?I guess it might be like typograph panels, which is yui-panels - saving mutual panels state (troublesome with single panel), modal mode, position of the panel, stacking panels, maybe some sort of tabs. Basically, photoshop-like panels functional. Not only it is settings-panel manager, but popoff manager as well. Conceptually.
But how does it do practically? Like
That might be useful for things like single-time modal panel