Mshell at 19:42, 14 July 2026

2026-07-14T19:42:09Z

← Older revision		Revision as of 19:42, 14 July 2026
Line 1:		Line 1:
	Yes—'''Flutter/Dart could be useful later for the iPhone and Android apps''', but I would not use Flutter as the primary technology for customizing the MediaWiki web application.		Yes—'''Flutter/Dart could be useful later for the iPhone and Android apps''', but I would not use Flutter as the primary technology for customizing the MediaWiki web application as part of the overall [[Production Architecture]].

	The strongest architecture is:		The strongest architecture is:

Mshell: Created page with "Yes—'''Flutter/Dart could be useful later for the iPhone and Android apps''', but I would not use Flutter as the primary technology for customizing the MediaWiki web application. The strongest architecture is: MediaWiki remains the core platform and system of record ↓ MediaWiki skin and extensions provide the web experience ↓ MediaWiki APIs expose application functionality ↓ Flutter provides an optional iOS/Android client 2026-07-14T19:41:33Z Created page with "Yes—'''Flutter/Dart could be useful later for the iPhone and Android apps''', but I would not use Flutter as the primary technology for customizing the MediaWiki web application. The strongest architecture is: <code>MediaWiki remains the core platform and system of record ↓ MediaWiki skin and extensions provide the web experience ↓ MediaWiki APIs expose application functionality ↓ Flutter provides an optional iOS/Android client</co..." New page Yes—'''Flutter/Dart could be useful later for the iPhone and Android apps''', but I would not use Flutter as the primary technology for customizing the MediaWiki web application. The strongest architecture is: <code>MediaWiki remains the core platform and system of record ↓ MediaWiki skin and extensions provide the web experience ↓ MediaWiki APIs expose application functionality ↓ Flutter provides an optional iOS/Android client</code> == For the web application: stay native to MediaWiki == For the web version, align closely with standard MediaWiki development practices: * '''PHP''' for extensions, business logic, hooks, permissions, special pages, and server-side features * '''JavaScript''' for interactive browser behavior * '''CSS/LESS''' and a MediaWiki skin for visual customization * <code>extension.json</code> and <code>skin.json</code> for standard extension registration MediaWiki explicitly supports customization through skins and extensions. Its documentation notes that skins control appearance, while extensions customize how MediaWiki works. Basic skin work can be done largely with CSS, JavaScript, and JSON; PHP becomes useful for more advanced behavior. (MediaWiki) That approach gives GoalStriving several advantages: * MediaWiki developers can understand and contribute to it. * Your code can potentially be distributed as conventional MediaWiki extensions or skins. * You can reuse standard authentication, permissions, page history, templates, categories, notifications, and extension hooks. * MediaWiki upgrades will be easier than if you replace the normal interface with an unrelated frontend framework. I would avoid building the web version itself in Flutter Web. Technically Flutter supports web deployment, but it would make GoalStriving feel less like a native MediaWiki project and could complicate accessibility, search indexing, browser behavior, extension compatibility, and community contribution. Flutter’s cross-platform capability is real, but its strongest role here is as a separate mobile client. (Flutter Docs) == For mobile: Flutter is a reasonable choice == Once the MediaWiki web application and its data model are stable, Flutter could provide one shared codebase for: * iPhone * Android * potentially desktop apps later Flutter officially supports mobile, web, and desktop deployment from a shared Dart codebase. (Flutter Docs) A GoalStriving mobile app could offer a more focused experience than the full wiki interface: * View goals and current priorities * Add progress updates * Complete daily or weekly check-ins * Receive reminders * Record journal entries * Upload photographs * Work offline and synchronize later * Display dashboards and progress charts * Use mobile notifications and biometric authentication The app would communicate with MediaWiki rather than replace it. == MediaWiki should remain the backend == MediaWiki provides both an Action API and a REST API. The Action API currently offers broader functionality, while the REST API provides newer, more structured HTTP endpoints. Extensions can also register their own REST endpoints. (MediaWiki) For GoalStriving, you may eventually create API endpoints such as: <code>GET /goalstriving/v1/goals GET /goalstriving/v1/goals/{id} POST /goalstriving/v1/goals POST /goalstriving/v1/checkins GET /goalstriving/v1/dashboard</code> Those endpoints could be supplied by a normal MediaWiki PHP extension. The Flutter app would consume them using JSON. This separation is valuable: <code>MediaWiki extension - Defines goals - Enforces permissions - Stores or retrieves information - Implements workflow rules - Exposes REST endpoints Flutter app - Presents the mobile interface - Handles navigation - Stores temporary offline data - Calls MediaWiki APIs - Uses phone-specific features</code> == Important design decision: pages versus structured records == Before building the mobile app, determine how GoalStriving data will be represented. You might store goals as: # Ordinary wiki pages with templates # Semantic MediaWiki properties # Cargo records # Custom MediaWiki database tables # A hybrid of pages and structured records For community alignment, a hybrid is likely strongest: * Human-readable wiki pages remain the durable content. * Templates, Semantic MediaWiki, or Cargo provide structured fields. * A GoalStriving extension provides workflow and API functionality. * Flutter consumes the structured representation. For example: <code>Goal page ├── Title ├── Description ├── Owner ├── Status ├── Target date ├── Motivational priority ├── Progress entries └── Related goals</code> The same information could be edited through: * standard MediaWiki forms, * a customized web interface, * or the Flutter mobile app. == How to remain aligned with the MediaWiki community == I would follow several principles. === Build standard extensions rather than modifying MediaWiki core === Do not directly edit core MediaWiki PHP files. Put GoalStriving functionality into independently installable extensions and skins. MediaWiki’s supported customization model is explicitly based on extension points, hooks, extensions, skins, gadgets, and APIs. (MediaWiki) === Keep the normal wiki usable === The project should still work through a browser without the Flutter app. Mobile users who do not install the app should be able to use a responsive MediaWiki interface. === Use open standards and documented APIs === Prefer: * MediaWiki REST endpoints * Action API where necessary * OAuth or another supported authentication approach * JSON * standard MediaWiki page and revision concepts === Open-source the MediaWiki components === A clearly separated collection could be appealing to the community: <code>GoalStriving extension GoalStriving skin or skin customization GoalStriving templates GoalStriving Page Forms GoalStriving mobile app</code> Someone might adopt only the extension or templates without using the mobile app. === Treat Flutter as a client, not the platform === This distinction will help community acceptance. GoalStriving would remain a MediaWiki application that happens to offer a Flutter mobile client—not a Flutter product that merely uses MediaWiki as an incidental database. == Recommended development roadmap == === Phase 1: Define the MediaWiki data model === Decide how these concepts are represented: * goals * projects * progress updates * habits * motivational priorities * users and groups * privacy * relationships among goals === Phase 2: Build the web experience natively === Use: <code>PHP MediaWiki extension JavaScript CSS/LESS MediaWiki skin or skin customization Page Forms / Semantic MediaWiki / Cargo as appropriate</code> === Phase 3: Create an API boundary === Do not let the future app depend on scraping HTML pages. Expose stable structured API responses from the GoalStriving extension. === Phase 4: Build a small Flutter proof of concept === Start with only: * login * list goals * view one goal * add progress update This will expose any weaknesses in the API and data model before you build the full app. === Phase 5: Add mobile-specific value === Add features that justify installing an app: * notifications * offline access * quick check-ins * camera uploads * widgets * biometric login * calendar integration == My recommendation == Use this technology allocation: {| class="wikitable" !Layer !Recommended technology |- |Core platform |MediaWiki |- |Server-side customization |PHP extension |- |Web UI behavior |JavaScript |- |Web appearance |MediaWiki skin, CSS/LESS |- |Structured data |Semantic MediaWiki, Cargo, custom tables, or hybrid |- |API |MediaWiki REST API plus extension-specific endpoints |- |iOS/Android |Flutter/Dart |- |Authentication |MediaWiki-compatible OAuth/session approach |} Flutter is therefore a good potential fit, but '''only after the MediaWiki application, data model, and API are stable'''. Your immediate learning investment should probably remain PHP, MediaWiki extension architecture, JavaScript, and MediaWiki APIs. Dart becomes worthwhile when the mobile client becomes an active development phase.

Flutter Dart - Revision history

Mshell at 19:42, 14 July 2026